Actually there isn't enough code in the GUI layer to complicate the situation... only the list, and the select done upon some simple name  filtering.
I've tried to turn the result set into a list and it does improve the response BUT it takes like 655 ms and if this is how it reacts now with only 3000 items... how will it act with 30000? how about 300000? This is why I wanted to use a virtual list... to fetch only the needed data.

I know there is supposed to be a performance hit with ordering BUT when converting the code to pure pysqlite it works way faster, I get something like between 45 and 70ms. Twice as bad would have been ok... but ten times slower?
I thought that maybe there is something I'm missing, like an optimization flag, or maybe a different way to approach it...

Anyway... I'll still use SQLObject.... ;) turning the result into a list, with one letter in the filter field is fast enough for now... ;)

On 2/23/07, Oleg Broytmann <> wrote:
On Fri, Feb 23, 2007 at 10:20:21PM +0200, Peter Damoc wrote:
> Everything work decently well if I don't use the orderBy clause...
> If I do use it the entire GUI slows to a crawl

   IWBN if you do an experiment to find out who is responsible for the
slowness. First, run the program in a command-line script and add the "for"
loop around it:

for patient in
   print patient

   Then, if the script works fast enough, draw all patients as a list:

patients = list(

   and use the list in your wxPython program. If the program is still slow
then the slowness is in wxPython.

     Oleg Broytmann    
           Programmers don't die, they just GOSUB without RETURN.

Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
sqlobject-discuss mailing list

There is NO FATE, we are the creators.