Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
INDEXSEEK()
Message
From
12/11/2001 08:29:11
Mike Yearwood
Toronto, Ontario, Canada
 
 
To
11/11/2001 22:41:39
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Title:
Miscellaneous
Thread ID:
00580322
Message ID:
00580417
Views:
17
Hi David

Once you issue SET FILTER and then GO TOP or GO BOTTOM, the dataset should already be "in memory". It should not be necessary to issue GO BOTTOM / GO TOP after each seek. I'd expect the record pointer movement to be slower than a seek without an active filter. SEEK is not rushmore aware. If the seek lands on a record that is subsequently excluded by a filter, it will take time to move to the next record.

You might try using LOCATE instead of GO BOTTOM. GO TOP / GO BOTTOM are also not Rushmore aware commands, and I suspect Larry is trying to reduce your overall timings. I thought you're trying to contract seek vs indexseek. IMO as long as you're using the same command after the seek/indexseek, you're still comparing apples to apples.

>The GO BOTTOM has to be there to validly compare the processes. It's the differences that important.
>Think about it, if INDEXSEEK has to respect filter conditions, and the set deleted on, then the dataset has to be accessed and paged into memory to determine this. The filter info, including the delete mark, is not in the index.
>
>
>>David,
>>Are you sure it is the INDEXSEEK/SEEK that is making things slower? It may be the GO BOTT. GO BOTTOM/GO TOP are very slow (relatively) when filters are in place. Take those out and see what the results are.
>>
>>FYI, others have posted here they now use INDEXSEEK instead of SEEK even if they want to have the record pointer moved. It has proved to be faster.
>>
>>>Initially I thought INDEXSEEK() would be a great command, saving some network load etc by not moving the record pointer, until I realised that it respects SET DELETED and SET FILTER. In which case it HAS to move the record pointer and then move it back. That makes it slower than SEEK()
>>>Since we run with SET DELETED ON in nearly all cases that's sad!
>>>
>>>Here's some code that you could modify to test your own files....
>>>local i, t
>>>* Assume RMast is open
>>>set filter to
>>>
>>>* NOTE: Rnum=2 is a deleted record and Active=.F.!
>>>
>>>t= seconds()
>>>set deleted on
>>>for i = 1 to 100000
>>>	 =seek(2, 'Rmast', 'RNum')
>>>	 go bott
>>>endfor
>>>? 'Old SEEK took ' + str(seconds()-t, 12,2)
>>>* Ave: 1.00
>>>
>>>t= seconds()
>>>set deleted on
>>>for i = 1 to 100000
>>>	 indexseek(2, .F., 'Rmast', 'RNum')
>>>	 go bott
>>>endfor
>>>? 'Indexseek DELETED ON took ' + str(seconds()-t, 12,2)
>>>* Ave: 1.06
>>>
>>>t= seconds()
>>>set deleted off
>>>for i = 1 to 100000
>>>	 indexseek(2, .F., 'Rmast', 'RNum')
>>>	 go bott
>>>endfor
>>>? 'Indexseek DELETED OFF took ' + str(seconds()-t, 12,2)
>>>* Ave 0.63
>>>
>>>set filter to Active
>>>t= seconds()
>>>set deleted off
>>>for i = 1 to 100000
>>>	 indexseek(2, .F., 'Rmast', 'RNum')
>>>	 go bott
>>>endfor
>>>? 'Indexseek DELETED OFF, FILTER ON took ' + str(seconds()-t, 12,2)
>>>* Ave 1.38
>>>
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform