Re: %lookup

[Hans Boldt <boldt@xxxxxxxxxx>]

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