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.

> I should stress that  
> the amount of instantiations can reach into thousands easily for me. I  
> know this maybe a niche problem and for 10-30 objects the speed is good.

   Still I'd resolve the issue to at least some extent.

> I have attached the python -m cProfile output, and limited the run to  
> 'only' (?!) 40,000 objects. Hopefully this may make some more sense to  
> you. Gprof is.. definitely.. urm.. quirky :)

>    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?

>         1    0.000    0.000   85.863   85.863 <string>:1(<module>)

   This is AFAIU the entire script? :)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            p...@phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

------------------------------------------------------------------------------
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Reply via email to