i modified a few things in this test, to get a better picture of the speed we really care about. as it turns out, not much changes. the change is, to insure that the mappers are compiled using the compile() step, and then start the timer, using the "time" module in python. so heres the typical results I get, with the internal test time denoted by "total time":
SA 0.3 latest trunk: STARTING NOW 2006-12-04 13:52:18.174562: Loading sis 2006-12-04 13:52:20.371373: 377 sis loaded 2006-12-04 13:52:20.372281: Creating indicators 2006-12-04 13:52:20.552949: 127 indicators created 2006-12-04 13:52:20.554647: registering... 2006-12-04 13:52:20.619494: ok done ! total time 2.44655799866 real 0m3.315s user 0m2.364s sys 0m0.388s using 0.2.8: STARTING NOW 2006-12-04 13:52:39.104842: Loading sis 2006-12-04 13:52:40.367581: 377 sis loaded 2006-12-04 13:52:40.368476: Creating indicators 2006-12-04 13:52:40.591517: 127 indicators created 2006-12-04 13:52:40.593057: registering... 2006-12-04 13:52:40.621836: ok done ! total time 1.51871609688 real 0m2.398s user 0m1.488s sys 0m0.382s still, these are not earth-shattering time differences (whereas 200-300% is)...the architecture of 0.3 versus 0.2.8 with regards to the construction of mappers has been reworked to be a lot simpler and clearer, and therefore much easier to work with, with regards to insuring that features work correctly (like mapper options) and that new features can be added. so theres a little more decision making going on (such as in the interfaces package) whereas in 0.2.8 the structure of mappers was a lot more byzantine but produced a slightly smaller call-chain in some cases (notably, 0.3 has a two-or-three hop path from MapperProperty->eager loading code, whereas in 0.2.8 it was all just one object. although i tried reducing that distance as a test and it made no speed difference at all...typical python). i dont have time to get more deeply into the cause of these differences right now but im hoping there is something somewhat obvious going on, possibly the MapperExtension calls are adding some overhead that can be reduced. but trust me, the architecture of 0.2.8 was a total mess compared to 0.3, and it doesnt help anyone if the code is so confusing that nobody except me can work with it....i still think we are better off. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
