Moving from Vcursor to Vsets

[Ruslan Zasukhin]

On 20/7/07 11:49 AM, "Dave Addey" <listmail1 at dsl.pipex.com> wrote:

Hi Dave,

>> ------------------------------
>> Steps are:
>> 
>> 1) SEARCH in PlaylistTracks table
>> 
>>     set1 = PlaylistTracks.PlaylistUniqueIDPtr.FindValue( 3 )
> 
> This is very quick.
> 
>> 2) FIND linked records from table Tracks
>> 
>>     set2 = linkFK.FindLinked( PlaylistTracks, Tracks, set1 )
> 
> For a small set from 1), this is also very quick.  For a large set (70,000
> records, VLink.FindLinkedAsBitSet can take 4 or 5 seconds.  So maybe this
> isn't the way for me to do it.

A) but why you get so big set ?

B) 70,000 records from table PlayListTracks ...
    and they are linked to how much records in Tracks?

You have told you use Foreign Key design.
Try switch to ObjectPtr -- this may speed up things in 4 times.

 
>>> I¹ve been doing it the VCursor way so far, but some of my SELECT statements
>>> take too long to execute, so I want to chop them up into smaller chunks.
>>> I¹m thinking of doing this using several VSet methods, each of which reduces
>>> the set another step, bit by bit.
>> 
>> May be better find why they are slow. May be indexes are missing.
> 
> Actually, they aren't that "slow" - it's just that the SQL is reasonably
> complex (table JOIN, multiple ORDER BY fields, multiple LIKE statements).
> The problem is, I'm playing QuickTime audio on the main thread, and
> *anything* which takes a while to complete ( > 0.5sec ) can cause the audio
> to drop out.
> 
> I think I may just need to find a way to perform my large SQL selects on a
> background thread.  No matter how much I speed things up, or no matter how
> much I chop the select / order / find into smaller VSets, someone will still
> do a large enough search on a slow enough machine, and get audio dropouts.

-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]