[Info-vax] improve performance of /EXCLUDE

[Stephen Hoffman]

On 2015-01-27 23:45:27 +0000, mcleanjoh at gmail.com said:

> What difference do larger RMS buffers make to the search time?

It seems you might have little experience with a system that offers a 
faster search?

As compared with a modern search?   No.   A modern search is not that 
much slower than the results from a Google search, for instance.    If 
you're referring to speeding an old-style search, I'd not expect larger 
buffers to help all that much.  It's down to how big the I/O requests 
and the associated and inherently sequential processing is.  You can 
only make a search go so fast through most any file system — it's only 
as fast as the file system and the storage — or you use a more modern 
and caching search.

> I once wrote a 'copy' program (with an entry point to make it callable) 
> that saw how much memory I had available (i.e. WSMAX less current 
> allocation) and used a large chunk of that as the copy buffer.  I 
> *think* it was faster than normal copy but it wasn't easy to check this 
> because on the first run the file got cached on the SAN and read access 
> fell quite a bit. A 'search' using a similar system might be very fast.

There would be some interest around faster plug-ins, but that stuff 
runs in the background.  An analog found in various Unix systems is the 
locate command — that's nowhere near the search grammar supported by OS 
X mdfind, or what ht:/Dig could get you, but it's still faster than 
slogging through the directories using a traditional find or SEARCH 
search.

-- 
Pure Personal Opinion | HoffmanLabs LLC