Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Locate in large table
Message
From
21/04/2009 08:55:29
Mike Yearwood
Toronto, Ontario, Canada
 
 
To
20/04/2009 19:41:10
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
01394873
Message ID:
01395742
Views:
83
>>>>>Of course it's optimizable.
>>>>
>>>>
>>>>I didn't mean documentation wise.
>>>>Cetin
>>>
>>>Same here. It is optimizable by observing the performance difference, not just by what the documentation says.
>>
>>Mike,
>>My real world experience tells "locate" is slow that I wouldn't expect from a rushmore optimization (and yes I am talking about full optmizable expressions). I really can demonstrate and already published some code about it on foxite about a year ago or so. What I couldn't differentiate is if that is locate itself what is slow or Rushmore optimization is not as a big optimization as we always believed. A typical example is patient visits. A visits table have patientId (foreign key) and visitDate. Both indexed. When such a table have many records and on a network to augment its importance more:
>>-Try locating a given patientID'd records that are between dStart and dEnd.
>>-Next try just retrieving all records of that given Id and then filtering for date locally
>
>IIRC, once upon a time we had some theoretical explanation for the behavior of Locate: it builds a bit map of records that it finds. Depending on the size of the table, the physical layout of these records in the table etc, this map may take some time to build - but then a loop with do while found() and a Continue before the end of the loop would be blazingly fast.
>
>Being spoiled by Scan/Endscan's elegance, I haven't tried this ever since. The Locate/Continue looks somewhat clumsy, compared with Scan/Endscan, so it seems I'm avoiding it. Maybe I shouldn't... but I just don't think in that direction.

From Rushmore's perspective only SCAN+ENDSCAN = LOCATE+CONTINUE # SQL

SEEK first is often faster, but you cannot build a system only using seek and then make that work with a different backend. I prefer one approach. For me, Seek is relegated to incremental searches in SQL generated cursors and indexes are only to show the SQL generated cursors in different orders.

>
>>seek()+locate while however works fast. Hope it is clear now.
>
>Still haven't found anything that beats "seek+scan while"'s speed.

seek + locate while = seek + scan while from Rushmore's perspective.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform