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/ [email protected]
Programmers don't die, they just GOSUB without RETURN.
------------------------------------------------------------------------------
_______________________________________________
sqlobject-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
