Re: Array vs file access

Joe Pluta wrote:

I think reading small tables into memory is an acceptable practice; I've
used it throughout my career. The idea that paging will bring the
records into memory is a nice thought, but eventually you run out of
memory and things get swapped and usually at the time you need them
most. If you decide to go the no array route and want to ensure that a
file is in memory, you might want to consider the SETOBJACC command. In
any case, run some comparisons to see which way actually performs
better; the last I checked, arrays still process faster than database
files.

I concur with Joe, I myself strenuously noting that trying to solve a
performance problem in one's head is impossible. Code that runs very
fast with my database, my workload and my memory configuration might be
a very poor performer for you.

Consider Joe's comment about the CHAINed records being swapped out when
you need it most. That's completely true. It's also true that if one
constrains the subsystem's memory pool a little bit more, i5/OS will
start swapping out array pages, too.

I strongly recommend running performance tools and gathering statistics
on your existing process. It might turn out that a smallish adjustment
to your memory allocations will boost your performance quite a bit. Or
it may turn out that your 800 records are far past the tipping point and
you'd need a lot more memory to keep them all paged in. Another
alternative might be to shift some of the workload around, to free up
what memory you have. The point is that without hard data it is very,
very difficult to give good advice.
--buck