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



Steve Richter wrote:

we are talking RPG, the predominant language on the i5. Limitless
arrays have to exist on the heap. Standard RPG arrays are allocated on
the call stack. It takes more CPU to alloc from the heap than from the
call stack.  Once you alloc from the heap you have to run cleanup code
to dealloc the limitless array. To do that correctly you probably have
to run CEERTX to make sure all the allocations are freed. This sort of
thing takes more CPW to do. You can argue how much, but you make no
sense if you are saying there is no impact.


Steve, at runtime, there is lots of heap allocation going on under the
covers, some in the RPG runtime, some in the system.  There is also lots
of cancel handling.  If IBM decided that RPG should have unbounded
arrays, the fact that it might require additional heap allocation and
cancel handlers would not be a deterrent to providing that support. 
(The V5R4 XML support uses heap allocation and cancel handlers. 
XML-INTO sometimes takes quite a bit of time to run depending on the
size of the XML document, but very little of the time is related to
either heap allocation or cancel handling.)

Are you sure that the time to allocate from the call stack is faster
than allocating from the heap?  How can you tell?  (I don't know whether
it is or not, but I doubt that it's a significant difference.)


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.