×
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.
Jon Paris wrote:
>> That's much easier, and probably faster too.
_Now_ who's talking performance without testing it! <grin>
My experience has been that it can be significantly faster to do a %lookup
than a SETLL or CHAIN. Particularly when only the existence of the key is
at issue and the other fields in the record are not required. Even when
SETOBJACC is used, the array will often outperform.
Don't forget that the addition of a logical view has performance
implications outside of the program in question. It will add overhead to
every program that updates the underlying physical file.
For years we've used SETLL/CHAIN _because_ the performance of LOOKUP stunk -
we've got a decent alternative now with %lookup - so why not use it?
Jon: You got me there! I realized after I sent that note that I would be
called on that point! ;-)
You're right - testing is important. Testing is needed to establish that
there might be a performance bottleneck in the lookup of that table. And
testing is needed to prove that a %LOOKUP on a pre-loaded table might
provide some improvement. For example, if you can eliminate one I/O
operation out of ten, then you might get a 10% performance improvement.
Is that a significant enough improvement?
My own inclination is to take the easy way out and program in the more
natural manner, taking full advantage of the capabilities of the
database whenever possible. That is, large tables belong in the
database. Only after the application is working correctly, should the
issue of performance be addressed, and then only if there is a perceived
problem in performance. At that point, you bring in the performance
analysis tools and you identify and address the bottlenecks, addressing
the biggest bottlenecks first.
Cheers! Hans
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
