In message
<[EMAIL PROTECTED]>,
"Baakkonen, Rodney A (Rod) 46K" <[EMAIL PROTECTED]> writes
I guess my point was a little off topic, as I was really calling
attention to performance issues with dynamic arrays in general and not
about sorting keys. When dynamic arrays can out perform work files, we
will use them.
We have seen processes that used dynamic arrays run for a week. Even
with doing REMOVE and using concatenation to build the array. Changing
the logic to use a work file resulted in the same process finishing in
hours.
The important question is, is the dynamic array small relative to the
server RAM. At my previous site, we sometimes manipulated dynamic arrays
in the megabyte range. On a server with 16Mb RAM serving an 80-person
company, that is a HUGE array. When I looked at the server, the
hard-disk light was on pretty much constantly. No wonder the server ran
slow - it was paging pretty much all the time.
Remember, Pick was originally designed to (approximately) use the hard
disk as a form of "permanent RAM", and to do so efficiently. If you
don't have the RAM then using work files is far more efficient than
paging. But if your data fits conveniently in RAM then it's often more
efficient to do that (unless the OS caches your disk in RAM and gets
better performance that way :-)
Dimensioned arrays give the advantage of indexed access without the
disadvantage of disk access. That said, I'd always use dynamic arrays
for the convenience unless I was worried about performance - if the
array is typically small or can be traversed with a REMOVE statement,
the hassle of a dimensioned array is rarely worth it.
Cheers,
Wol
--
Anthony W. Youngman <[EMAIL PROTECTED]>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
