RE: Based variables

["M. Lazarus" <mlazarus@xxxxxxxx>]

Ken,

At 12/11/00 01:12 PM -0500, you wrote:
> >  It just seems to be a waste for the system to keep allocating the same
> >data over and over again. So if I have 4,500 records, I've ALLOCated 4,500
> >times instead of 9 times.
>
>The ALLOC and REALLOC operations allocate memory in multiples of 4K.  So if
>you allocate 240 bytes, then turn around and REALLOC for 480 bytes,
>persumably the memory allocation handler is smart to realize that the memory
>is actually already allocated and just return a sucess code, keeping the
>process very fast until an additional 4K is actually allocated.

  Have you tested this?  I'm curious if ALLOC has the smarts for that.


>So for efficiency you should never make a request that would be satisified
>within the same multiple of 4K as you have already requested.

  If the system is smart enough, then it shouldn't make much difference, right?


>So an alternate method of allocation, in place of allocating memory based on
>some number of elements to be held, is to allocate memory in chunks based on
>4K or some multiple thereof, then calculate how many elements can fit.

  The record length in this case is 148.  I'm expecting (at this time) a 
maximum of 4000-5000 records.  Minimum is one record.  So I picked an 
incremental of 500 as a reasonable number.  I'm using a based DS, so I can 
potentially allocate a little over 113,000 records at one time. Then I'm 
"shifting around" another DS as a "view" to each iteration of the 
data.  That should give us plenty of elbow room.

  My concern as far as performance if I were to only allocate one 
additional record at a time is that (4K allocation chunk notwithstanding - 
it's only 27 records!) the system will probably need to keep copying the 
existing data and add on the requested space.  A lot of unnecessary data 
movement.


  -mark

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---