Re: [SQLObject] SQLObject Speed ?

[Stef T. <st...@um...>]

Oleg Broytmann wrote:
> On Wed, Jul 22, 2009 at 02:26:57PM -0400, Stef Telford wrote:
>   
>>>> yes. evals appear to be  a 'bad' thing here :\
>>>>         
>>>    Well, those evals are in sqlmeta.addColumn and .addJoin methods, so they
>>> work once for every column in the table, but that's all. After the class
>>> has been created and populated - whatever you do with rows (class instances)
>>> - those evals are not executed.
>>>
>>>       
>> Ah. hrm. *rubs chin* perhaps it's not the evals then. It seems that the  
>> instantiations get .. well .. 'slower' over time.
>>     
>
>    Curiouser and curiouser. IWBN to find where the slowness is *near the
> end* of the loop - i.e. when instantiation becomes really slow.
>
>   
It could be purely a 'feeling' .. I don't have any numbers to back it up 
and I am not entirely sure -how- to benchmark that. This machine does 
have 8gb of ram in it, and a fairly beefy quad core. I have never seen 
any process get near memory exhaustion, which I could believe the calls 
to 'malloc' could slow down but.. yes.

>>    Ordered by: standard name
>>
>>    ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>>     40000    0.063    0.000    0.141    0.000 <string>:1(<lambda>)
>>     
>
>    Can you sort by ncalls and cumtime columns, cut the first 100-200 lines
> and post two tables here?
>
>   
surely, please find the output attached at the bottom. It maybe also 
worth changing the Decimal call to using gmpy or .. something that's 
faster than Decimal perhaps ? I did notice a fair few cycles are spent 
in Decimal.__new__ .. I don't think that's the -entire- story, but it 
should help I would think.
>>         1    0.000    0.000   85.863   85.863 <string>:1(<module>)
>>     
>
>    This is AFAIU the entire script? :)
>
>   
Yes indeed.. that's the way I read the cProfile output as well :D

Regards
Stef