× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Based variables
  • From: bmorris@xxxxxxxxxx
  • Date: Mon, 11 Dec 2000 16:11:11 -0500
  • Importance: Normal


>Date: Mon, 11 Dec 2000 13:12:27 -0500
>From: "Sims, Ken" <KSIMS@SOUTHERNWINE.com>

>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.

Ken, what you say may be true of some system allocation functions (I
think the C runtime's realloc might work this way), but not all, and not
the one that RPG uses under the covers.  First, RPG always returns a
different pointer from a successful REALLOC, and second, the storage
isn't necessarily allocated in 4K chunks.  The program below displays 32.

D p1              s               *
D p2              s               *
C                   alloc     10            p1
C                   alloc     10            p2
C                   eval      num = p2 - p1
C                   dsply                   num               5 0
C                   dealloc                 p1
C                   dealloc                 p2
C                   return

This illustrates the problem with writing code that takes advantages
of peculiarities of the system.  If possible, even when you are coding
for improved performance, it's best to do it without system peculiarities
in mind.  In this case, the additional logic required to keep track of
both the "logical" length of the storage and the actual allocated length
is trivial to code and quick to run; allocating some multiple of what you
actually need will probably perform better no matter what's going on
under the covers.

In general, unless you have a really serious performance problem, it's
my opinion that it's better to code for maintainability rather than
for performance.  (Note that I'm not qualified to speak for IBM in
this regard, so take this last sentence for what it's worth, as written
by an ordinary programmer.)

Barbara Morris


+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.