Fair enough! That those benchmarks are not optimal is a good thing to know. (By the way, I did indeed run the DM tests first, but have re- run each of them in various orders with similar results (different in fractions of a second only).)
In practice, I certainly did not notice the app _feeling_ slow, nor have I noticed console work _feeling_ slow. The numbers were a big surprise to me. Piotr, thank you for those benchmarks. Could you, or anyone, really, point me down the path that leads to my understanding how to setup and run such benchmarks myself? It would be good to know how to recreate these things in the future. Plus, I'd like to run them personally, and report back to Indy.rb. :-) Thanks for the information, everyone. I appreciate the quick responses. MilesZS On May 16, 1:08 pm, Emmanuel Gomez <[email protected]> wrote: > On May 16, 2011, at 6:29 AM, Piotr Solnica wrote: > > > I wouldn't be worried about such micro benchmarks though. > > Agreed, Piotr. > > I haven't run any numbers myself, but in a more realistic setup, using some > of the features of DataMapper, your benchmark may turn the other direction. > Consider if you're using Devise for authentication in Rails 3, with a model > somewhat like this (I have explicitly declared all the fields that Devise > adds to an authenticated model, including several optional Devise 'modules'): > > class User > include DataMapper::Resource > > property :id, Serial > # devise :database_authenticatable > property :email, EmailAddress > property :encrypted_password, String, required: true, length: 128, lazy: > [:authenticatable] > > without_auto_validations do > # devise :recoverable > property :reset_password_token, String, lazy: [:recoverable] > property :reset_password_sent_at, DateTime, lazy: [:recoverable] if > Devise.reset_password_within.present? > # devise :rememberable > property :remember_token, String, lazy: [:rememberable] unless > Devise.use_salt_as_remember_token > property :remember_created_at,DateTime, lazy: [:rememberable] > # devise :trackable > property :sign_in_count, Integer, lazy: [:trackable], default: 0 > property :current_sign_in_at, DateTime, lazy: [:trackable] > property :last_sign_in_at, DateTime, lazy: [:trackable] > property :current_sign_in_ip, String, lazy: [:trackable] > property :last_sign_in_ip, String, lazy: [:trackable] > # devise :lockable > property :failed_attempts, Integer, lazy: [:lockable], default: 0 > property :locked_at, DateTime, lazy: [:lockable] > property :unlock_token, String, lazy: [:lockable] > end > > # Include default devise modules. This adds properties as needed. > devise :database_authenticatable, :lockable, :timeoutable, > :recoverable, :rememberable, :trackable, :validatable > # Also available: > # :token_authenticatable, :encryptable, :confirmable and :omniauthable > > end > > Note the lazy groups. This alone will cut down traffic to the data-store for > the vast majority of your queries. I haven't gone too far down this road, but > I'm pretty sure that Devise will provide a way to use your own query, in > which you can eagerly load :encrypted_password *for the one query when you > actually want it*. > > My point being: micro-benchmarks are right behind pre-mature optimization as > the root of many misled development efforts. > > HTH, > Emmanuel -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
