Hello again Oleg, Everyone Oleg Broytmann wrote: > Hi! > > On Wed, Jul 22, 2009 at 11:19:36AM -0400, Stef Telford wrote: > >> Hello Oleg, Everyone, >> Sorry for the delay in replying.. "real life" sort of got in the way. >> Deepest apologies for that. >> > > No problem. I understand the issue and feel your pain, sure. > > *chuckles* this is kind of the problem with OS projects. We use them almost 100% here at work but try to spend any -actual- time on improving them and.. well.. yes. >> When I benchmarked the SQLObject page of 7000+ objects (give or take >> a few hundred), I got the 80-90 seconds. With plain python objects, I >> got the 0.3 seconds (obviously a lot less going on, so, not surprising >> there). However, when I took out the evals inside sqlobject/main.py, I >> got the page speed to around 15-20 seconds. >> > > Aha, that's the results! Thank you! > > In what way have you "took out the evals"? You cannot just remove them so > you probably replaced them? with what? > > actually.. I -did- remark them out. As I said, all the evals do (I -believe-) is to add the lambda into the python dictionary with a specific name for getattr to find (I am probably horribly mangling pythonic terms here, and I apologise). I have read in numerous places that python's eval is hysterically slow, and I think that this is somewhat borne out. I know that (obviously) the code is missing so it's not a straight 1<->1 in terms of execution, but, yes. evals appear to be a 'bad' thing here :\ >> So, this raises the question, is it perhaps better to -not- use >> eval(..) and instead tinker with the objects __attributes__ or __dict__ >> ? I am not -that- conversant/knowledgeable in pythons black magic of >> object meta programming but.. I definitely think that if we can get away >> from calling 'evals' when doing object instantiation that would be a >> HUGE performance win. >> > > That requires some thinking and experimenting. Perhaps those evals > could be replaced with functools.partial - that requires python 2.5, so it > can be implemented after SQLObject 0.11 (which I'm gonna release RSN). > > functools partial ? isn't this another name for decorators ? I tend to get rather lost in python black magic as I said (sorry :). This said, stating python 2.5 as a 'baseline' is not a -bad- idea. It's been out in one form or another since sep 2006.. that's not exactly cutting edge ;)
I am still wondering though, can't we simply look into the python object's dictionary and place functions into there ? if there is an existing _SO_get_Blah and a user defined _SO_get_Blah then can't python rename the existing one and then include a call at the end to the newly placed one onto the end ? I know, this is monkey patching but.. isn't that what we are doing with the evals anyway ? >> And, in the process of putting my money where my mouth is, I am more >> than willing to donate $200 bounty for the fix, either to the person or >> charity of their choosing. >> > > Wow, what a generous offer! Thank you very much! > > Not a problem. I -do- use SQLObject day to day, and I figure that since my python skills would probably offend everyone should I try, then the least I can do is put my money where my mouth is :) >> (ps. I -do- have a large PNG of the system during a single 'page >> impression'. It's about 7mb .. I can send it offlist if your interested >> ?) >> > > A PNG of the system? What's that? I don't understand... > > It's a PNG of the profiling of a single 'page'. I profiled it and then passed it through gprof2dot ( http://code.google.com/p/jrfonseca/wiki/Gprof2Dot ) let me know if you want it.. it -is- a VERY large PNG though :) > Oleg. > Regards Stef ------------------------------------------------------------------------------ _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
