[Info-vax] improve performance of /EXCLUDE

[Paul Sture]

On 2015-01-27, mcleanjoh at gmail.com <mcleanjoh at gmail.com> wrote:

<snip>

> What difference do larger RMS buffers make to the search time?
>
> 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.

Going back to the  VMS V3/V4 era, I was convinced that SEARCH did such
an optimisation, because it could whip through files substantially
faster than other tools available.  A tailor made COBOL batch program
using the RESERVE clause in the file declaration to increase the number
of RMS buffers use would beat SEARCH every time, though IIRC this
depended on having sufficient free dynamic memory at run time.

But that was in the era of relatively slow hardware. What Hoff is
talking about when he mentions mdfind is the OS X search facility.

I na nutshell, worker processes index your files as you create them
so the information is already there when you want to do a search.
Want a new file type the system doesn't recognise? Write your own
plugin to feed the indexes with the data and the results from those
will be returned in searches.
-- 
Of dates and times:
%S - Second as decimal number (00–61), allowing for up to two leap-seconds
(but POSIX-compliant implementations will ignore leap seconds)