RE: Dynamic Arrays

On Wed, 16 Oct 2002, Booth Martin wrote:
>
> The fact that Visual Basic redimensions arrays only points out the
> shortcomings of being forced to do everything in volatile memory because the
> Microsoft Operating System is so disjointed and unpredictable.  I find the
> whole idea to be a weakness of Visual Basic and a strength of OS/400.
>

You aren't forced to do things in volatile memory because the operating
system is "disjointed and unpredictable."  I do agree that those terms are
accurate descriptions of Windows, but that's not why you use volatile
memory for those tasks.

Accessing memory is MUCH faster than accessing disk.  It's also MUCH
faster to access an element in an array than it is to access a record on
disk, even if that disk is a RAM disk.

The big difference here is that on a Windows system, you typically have
many megabytes of memory available to you, and that memory is only being
used to service ONE USER.   By contrast, if you use too much memory on an
iSeries, either the system will force your task to use disk instead of
memory (slowing you down) or you will eat up the RAM so that it can not
be used by other processes (slowing the rest of the system down)

This leads to a different paradigm in programming.  You use memory instead
of disk because it's faster.   You don't have to worry about other users,
because there aren't any.

If you were writing a computer game that had 30,000 different objects
(objects being things like walls, weapons, monsters, people, equipment,
etc) that needed to be interacting with the user all at the same time,
you wouldn't use an array?  really?   You'd use a database file, despite
that keyed access isn't needed, and that it would incur a LOT of overhead?

Please keep in mind that not every application is an accounting program,
and not every computer architecture is the same.

Allowing large arrays is never a weakness.   The weakness is computer
programmers who lack the understanding of how computers work, and
therefore use resources inefficiently.