Oleg Broytmann wrote:
> On Wed, Jul 22, 2009 at 05:18:46PM -0400, Stef Telford wrote:
>   
>>>>    Ordered by: cumulative time
>>>>
>>>>    ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>>>>         1    0.127    0.127   83.346   83.346 sresults.py:175(__iter__)
>>>>     40001    0.308    0.000   79.876    0.002 dbconnection.py:649(next)
>>>>         
>>>    Hmm. Does the program try to draw the entire table in one huge slurp?
>>>
>>>       
>> Actually, no. This page does 40k of bookings (a single object type) but  
>> the query isn't "Sequential" (it's not grabbing 0-40,000 is what I  
>> mean).
>>     
>
>    Hmm. One call to SelectResults.__iter__ that spans the entire program's
> lifetime. "One huge SELECT" is the only way I can interpret this.
>
>   
Hello Oleg,
    Sorry, I should have been more precise in my statement. The bookings 
-are- returned from one select/query via cursor but the bookings are not 
contiguous (eg, booking 300, booking 310, booking 423, etc). This said, 
I tried the select in psql and it worked in 19msec and then I tried from 
psycopg2 cursor and it took 3 seconds.. so.. I have to ask, why is it 
taking 23sec ?
>    So we have 29 seconds in Decimal.__new__, 10 seconds in fetchone, and 23
> seconds in _SO_selectInit. 63 seconds of 85...
>
>   
yup, and the next two are the notify method (which is similiar in way to 
publish/subscribers that I have added into sqlobject) and framestack 
(which is used in the notify method to stop circular references). I 
could rip those out but.. :\
>>>>     40000    0.214    0.000   23.323    0.001 main.py:912(_init)
>>>>     40000   10.475    0.000   23.069    0.001 main.py:1140(_SO_selectInit)
>>>>         
>>>    _SO_selectInit is a rather simple function - it populates the row with
>>> values just fetched from the DB; the values are converted using calls to
>>> to_python. Those to_python calls are fast (if we ca believe the profiler) -
>>> see above. So where does _SO_selectInit spend its time?!
>>>       
>
>    Well, it is certainly not evals. I also doubt it has something with
> garbage collection. Not in this function.
>
>   
hrm. could it be tied to the Decimal init's ? I mean to say, if we are 
seeing that those take a while to create, and each object has 10-14 
Decimals inside it.. hrm

Regards
Stef

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

Reply via email to