V4RB - 8.6, 9.22 Initial Query Slowdown

[Fitzbew at aol.com]

In a message dated 6/20/03 5:34:19 PM, sunshine at public.kherson.ua writes:


> on 6/20/03 23:20, Fitzbew at aol.com at Fitzbew at aol.com wrote:
> 
> > Ruslan (and others),
> >
> > I've experimented with cache sizes from 1 meg up to 300+ meg --- does not
> > affect the main problem of the "slow first query after restart". Yes, I
> > re-checked and this only happens in 8.9 and 9.2.2 -- not OS X.
> >
> > I have discovered that the slowdown is when I am calling NextRecord --- 
> the
> > first time cycling through the recordset is slow.  Building the recordset 
> is
> > (as always) very fast.  Still, like I said earlier, my app runs many 
> simple
> > queries at launch and calls NextRecord.  The recordset I am testing with 
> is
> > only
> > around 200 records.  I subsequently build the exact same recordset and
> > NextRecord cycles through it very quickly.  It is a very complex 
> recordset,
> > though --
> > many joins.
> >
> > The database is encrypted, if that might be a factor.
> >
> > Would calling NextRecord on a complex query require Valentina to do 
> something
> > for the first such query in a session but not for later queries? And only 
> in
> > Classic? 
> >
> > This has me puzzled.
> 
> Me too,
> 
> NextRecord() just read from disk to RAM cache.
> Speed should be the same on both OS 9 and X.
> 
> Do next: may be this is LISTBOX of RB cause you problems.
>     try comment output to list box and let only NextRecord() will remain.
> 

I've tried that already --- I've removed all code except building the 
recordset and cycling through it with NextRecord.bsp;  BUT --- I've used a stopwatch 
to time the OS X query, and there IS a slow down on OS X too when the first 
complex query is run, it's just not as obvious.   Sorry for misleading you.

So perhaps this is some "caching" process that slows down my app only during 
the first complex query?   I'm considering just "embedding" a complex query at 
app launch so that the first user-run query will be as fast as possible.   
(Certainly not an attractive solution.)

Russ