TIP OF THE DAY! Speed up re-indexing your files

[Kenneth Brody]

"Lerebours, Jose" wrote:
> 
> This might be applicable to those using *nix flavor
> of filePro to a degree - Have not tested it with
> windows version.
> 
> I've found that I can have my indexes rebuilt in less than
> half the time if I
> 
> 1. Use nice   (man nice)
> 2. Index each index individually instead of all of them
>    in a single dxmaint command
> 
>    Use dxmaint [filename] -r -e -o[INDEX]
> 
>    in lieu of
> 
>    dxmaint [filename] -e -ra
> 
> The latter will index all indexes A-P sequentially.  The
> first option gives you the option to open as many sessions
> as you want and rebuild an index per session.  That said,
> you can virtually rebuild all 16 indexes in the time that
> it takes to rebuild 2 of them.
[...]

When building indexes, part of the time is spent waiting for disk I/O to
complete.  (ie: reading the key file, dxmaint must wait until the O/S has
read the record into memory.)  Since all instances of dxmaint will be
reading the same key file, the odds are that the second and following
instances of dxmaint will be able to get the record from the cache, and
not have to wait for it to be read again.  (Building the indexes one
after the other, on the other hand, will probably mean that for a large
file, the first record is no longer in the cache by the time the last one
has been read, meaning that it will have to be read again to build the
next index.)  With the amount of memory available on modern computers,
you probably have enough memory to run 16 dxmaints all in memory, without
any swapping, meaning you may be able to eliminate as many as 15 out of
16 disk I/O waits for reading the key file.  Note, too, that dxmaint will
cache the index itself (assuming new-style indexes) while building it, so
there is no disk I/O for the index until it gets too large for memory.
(I don't recall the default cache size for dxmaint.)

The same holds true, as far as the filePro side of things, under Windows.
I can't speak for the Windows side of things, however I would expect it
to be basically the same.

-- 
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody        | www.hvcomputer.com |                             |
| kenbrody/at\spamcop.net | www.fptech.com     | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap at gmail.com>