On Oct 20, 3:54 pm, rogerdpack <[EMAIL PROTECTED]> wrote: > One thought I had recently... > If you ever get some of the old "free time" for datamapper, I have > noticed that the principles used by slim attributes[1], though > somewhat contrasting to that of datamapper, do allow one to load Mysql > rows very quickly [at least compared to ActiveRecord]. Might be worth > glancing at sometime. > Cheers! > -=R > [1]http://pennysmalls.com/2008/10/14/slim-attributes-v050-released/
Dan mentioned a bit about DO and avoiding generating intermediary strings. I think that's about as far as we can take the variable optimization with DM because we store the values directly in ivars. I'm sure you understand the implications of that, but for other curious members: So we type-cast directly on the C side to the desired Ruby type in DO, and hand it back to DM ready-to-go. Say you have 5 non-lazy fields by default you're bringing back. We assign each value to an ivar. The reason this can work in AR is that AR stores it's values in Hashes. So you have this "gateway" type object that you ask for your 5 fields. And you may never need 2 of those. So in the end, say you can save 40% of your type-casting work in AR with this. DM doesn't have a similar gateway. We could, but we're not going to. ;-) The downside of the current DM behavior is that Ruby is slow and C is fast. So shifting work to the C-side is an advantage today. But what about 6 months or a year down the road when you have the opportunity to use JRuby or IronRuby Strings? In DM, you'll be creating 5 very fast, cheap objects. In AR you'll be creating 1 complex object plus 3 cheap objects. I would expect DM to win by a large margin. So in the mean-time, I'd rather focus optimization efforts into other areas, like Query speed, the object loading cycle, pushing the cursors up as high as possible in the stack. The sort of optimizations that will (hopefully) pay off big no matter the platform. On my System creating 1 million Ruby Strings takes a half-second. Which is admittedly painfully slow. Still, that allows for two requests of 100,000 rows containing 10 Strings in 1s. On the other hand, for #get or #first requests, a lot more strings (and other objects) are going to be creating in just the Query, Collection and Adapter layers than in the final object. Other areas to look at for optimization would be the tracking, the number of dispatches a field goes through before it becomes an ivar in the load- cycle, the multiple hashes used for dirty-state, original-values, etc. So there's a good 5 or 6 areas for optimization. Because of the way DM works, I don't think the slim-attributes technique will translate all that well. -Sam --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
