Author: Michael J. Babcock, MCP
Posted: 2007-09-11 11:24:53 Link
I'm finding code where the developer had done a SET ORDER TO and then SEEK
command afterwards instead of using the SEEK(a,b,c) function with its
parts. I'm not sure when the SEEK(a,b,c) function came to be, so perhaps
this is because it was written prior to that?
IAC, I thought I had heard that doing a SET ORDER TO on a network table
was slow or caused a performance hit, especially since all we want to do
is use the index to check for the existence of a condition that could
nowadays be done with the SEEK(a,b,c) function. While refactoring, should
this be done (...replacing the old SET ORDER plus SEEK command with the
SEEK function instead)?
Just curious...tia!
--Michael
On Sep 11, 2007, at 12:24 PM, Michael J. Babcock, MCP wrote:
> IAC, I thought I had heard that doing a SET ORDER TO on a network
> table
> was slow or caused a performance hit, especially since all we want
> to do
> is use the index to check for the existence of a condition that could
> nowadays be done with the SEEK(a,b,c) function. While refactoring,
> should
> this be done (...replacing the old SET ORDER plus SEEK command with
> the
> SEEK function instead)?
You should know the answer by now: test both versions under actual
network conditions. There is a good chance that the current code is
not noticeably slower than the proposed new code; if so, you've just
saved a bunch of rewriting.
-- Ed Leafe
> > IAC, I thought I had heard that doing a SET ORDER TO on a network
> > table
> > was slow or caused a performance hit, especially since all we want
> > to do
> > is use the index to check for the existence of a condition that could
> > nowadays be done with the SEEK(a,b,c) function. While refactoring,
> > should
> > this be done (...replacing the old SET ORDER plus SEEK command with
> > the SEEK function instead)?
> You should know the answer by now: test both versions under actual
> network conditions. There is a good chance that the current code is
> not noticeably slower than the proposed new code; if so, you've just
> saved a bunch of rewriting.
Generally, with many files(some big, some small), I've noticed
considerable 'scan' speed increases by removing any orders set on the
cursor with 'set order to'.
I personally doubt there would be a significant speed difference
between SEEK() and SET ORDER TO...SEEK itself, but if the ORDER is
left set on the file and subsequent record pointer changes are done,
it could slow things down-- but be very careful about removing the SET
ORDER TO's, as that order could be critical to the logic of the code
itself...
--
Derek