#1453 ✓resolved
Michael Morris

Each request in development slows down subsequent responses

Reported by Michael Morris | December 9th, 2010 @ 05:14 AM | in 1.1

Requests to the rails stack (with dm-rails, dm-postgres) in development irrespective as to whether a model is queried, cause the next response to be slightly slower.

The problem is exacerbated in larger apps. On a larger app (20 models), we're noticing respones times in dev increase cumulatively by +20msec per/req which adds up very quickly.

I have setup a very barebones app with one model at https://github.com/mtcmorris/dm-problem. No data is required to be in the database - just the existence of a model

To replicate

  1. Clone, db:create, db:automigrate and start the app.
  2. Run @ben_h's schmark which runs many requests against localhost:3000

    ruby script/ben-schmark.rb

Over many hunderds of requests, the response time increases. This does not happen with just activerecord leading me to think it is a problem with dm-rails. I've tested with dm-sqlite-adapter and with the postgres adapter - they both exhibit the same result of slowing down the dev environment over time.

Comments and changes to this ticket

  • Xavier Shay

    Xavier Shay December 9th, 2010 @ 04:31 PM

    • State changed from “new” to “unconfirmed”
    • Assigned user set to “Xavier Shay”
  • Xavier Shay

    Xavier Shay December 9th, 2010 @ 08:39 PM

    • State changed from “unconfirmed” to “accepted”
    • Tag set to dm-rails

    The problem is that reloading the models does not reset Model.dependencies, meaning that on every request when the model is reloaded DataMapper::Model.extended is adding a new object to .descendants, causing unchecked growth over time.

    I have a hacky fix in my fork:

    I will test this on our app over the next week, clean it up, then commit to the main repo. Will also bring it up on IRC to see if there are any unintended consequences of clearing out the descendants array.

  • Martin Gamsjaeger (snusnu)

    Martin Gamsjaeger (snusnu) December 10th, 2010 @ 10:42 AM


    Because you've mentioned the missing set semantics for DescendantSet. I've started work on #1398 and will make sure that it's a set while doing so.

  • Martin Gamsjaeger (snusnu)

    Martin Gamsjaeger (snusnu) December 11th, 2010 @ 12:09 AM

    I've pushed a branch that should resolve #1398 and probably this one as well. The DescendantSet in my branch actually implements Set semantics. It'd be cool if someone could verify this?

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) January 13th, 2011 @ 09:31 PM

    • State changed from “accepted” to “resolved”

    (from [2ffa59f0963c3a33be72ae2796f0d5d286c7d863]) Implement true set semantics for DescendantSet

    Backing the DescendantSet with a SubjectSet makes
    sure that when new a new constant with the same
    name gets added (as is the case after code reloads
    in dm-rails), the old constant with the same name
    gets updated instead of the new one being appended.

    To make this work, a change to the way we construct
    anonymous join models was needed. Previously, we
    were first creating a new model class using
    Model.new, and then we assigned that class to the
    desired constant name. The problem with this is
    that the anonymous model got added to the
    DescendantSet at a time where it's desired name
    hasn't yet been set. This left us with an entry in
    the DescendantSet that wasn't identified by the
    correct name.

    This patch changes the method signature of the
    semipublic DataMapper::Model.new method:

    module DataMapper

    # OLD:
    # The storage_name parameter has been
    # deprecated since Jan 2, 2009
    # see: http://is.gd/e0q1RU
    Model.new(storage_name = nil, &block)
    # NEW:
    Model.new(name = nil, namespace = nil, &block)


    The new signature expects "name" to be a String
    and "namespace" to be a constant that will hold
    the newly created model.

    [#1453 state:resolved] https://github.com/datamapper/dm-core/commit/2ffa59f0963c3a33be72ae...

  • Martin Gamsjaeger (snusnu)

    Martin Gamsjaeger (snusnu) January 13th, 2011 @ 09:33 PM

    • Milestone set to 1.1
    • Milestone order changed from “196311” to “0”
  • Martin Gamsjaeger (snusnu)

    Martin Gamsjaeger (snusnu) January 13th, 2011 @ 09:33 PM

    • Assigned user changed from “Xavier Shay” to “Martin Gamsjaeger (snusnu)”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »


Referenced by