On 1/31/06, Nilson Santos Figueiredo Junior <[EMAIL PROTECTED]> wrote: > Anyway, I re-run the tests with the changes you mentioned and, > unfortunately, only CDBI performance improved. Now CDBI is slightly > faster than RDBO, even with RDBO prefetching the objects and CDBI > doing no prefetching. The changes are exactly what you suggested. The > benchmark results: > > RDB 43.3/s -- -0% -78% > CDBI 43.4/s 0% -- -78% > ObjRelMap 198/s 357% 356% --
I'm not surprised. Again, remember what you're testing: SQL generation and object instantiation speed. RDBO's SQL generator is much more complex (and much more capable) than CDBI's, so it's not surprising that it has more overhead when creating a simple query. (Again, one possible way to improve SQL generation performance in RDBO is to hard-code the SQL using make_manager_method_from_sql() or get_objects_from_sql(). Check the Rose::DB::Object::Manager docs for examples.) For object instantiation, RDBO calls the mutator method for each column when setting column values, whereas CDBI does a direct hash copy. Given this, it's actually surprising the RDBO comes as close as it does. As you can imagine, calling the mutator every time makes it a lot easier to support certain kinds of customization. So here, RDBO is trading sped for extensibility. Finally, there's the extra query for the related object. If the rows are few and the MySQL db has "spooled up" and everything is in memory, the extra queries run by CDBI may not be a significant penalty. But for a situation where many rows are pulled from an active db that is not entirely in memory (and may have a higher per-query overhead than MySQL, e.g. Postgres), the results would be very different. Only you know which situation is more representative of your actual task. > ObjRelMap represents the in-house ORM implementation I mentioned. Of > course that as a whole it's less sofisticated than any of the current > standard solutions (CDBI, Sweet, DBIC or RDBO) but it has built-in > auto-joins with multi-level prefetching (which could be further > improved since currently several queries might be dispatched), caching > and can handle low-to-medium complexity queries which are enough for > my current purposes. As always, less overhead == faster. Every ORM has to strike a balance between features and speed. RDBO is the balance I find best suited to my needs. YMMV :) > I think that when I've got the time I'll try to run these benchmarks > under the profiler so I can better understand what exactly is causing > RDBO to be slowed down. I hope I've shed some light on that. If you profile the RDBO example, my guess is that you'll see the auto-generated "anonymous" column mutator method(s) near the top of the profile if you are fetching many rows, and the get_objects() and/or build_select() subs near the top if you are not. -John ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
