×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Yes, it was certainly justified - memory access (array lookup) will always
be quicker than file I/O. Is it still justified? Probably - unless it's
actually broken, there's no need to fix it.
It makes an *excellent* candidate for encapsulation. When you do this, you
could simply make the array as large as possible, load it in kwyed sequence
(which you may already be doing) and use %lookup with 4 parameters. If more
records get added to the file, the array will cope with them (until/unless
you add too many for even the largest array to handle).
Rory
p.s. FWIW, I use this technique *a lot* - like with about 30
programs/modules/procedures. But I'm writing CGI programs where I need every
ounce of speed I can get.
p.p.s. If there are problems at runtime, it's nice to be able to debug the
program and see all the records. Or, if you use the DUMP opcode, it will
dump the entire array - if you're just using a file, you'll only get a
single record
p.p.p.s. If you do change to use direct file access, I like Albert York's
idea about caching the last few records, especially if, as he says, there
are certain records that get accessed more frequently than others.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
