|
On 1/31/06, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote: > > > > Would that affect your recommendation? If it doesn't, I'd still like to > > know why you advise using dynamic memory allocation. Is it *that* > messy? > > Okay, 20000 elements of 30 bytes each, times 50 users, times 2 (figuring > that's the average number of times it'll be loaded by each user?) at least three, average probably four. would be > around 58mb. Remember, the iSeries will store the stuff that doesn't get > much use on disk, and the stuff that's heavily used will be in RAM. Do > you think that 58mb where the vast majority is on disk will be a problem > on your system? This may be a Windows mindset (forgive me), but doesn't swapping between memory and disk tend to impact performance as well? Maybe not as much as Windows? The only reason I advise against the dynamic allocation is because it's > extra work, it's easy to make mistakes that are difficult to debug > (especially for someone who's new to it) and it's usually unnecessary when > working with so few elements. How much does 64mb of memory cost in > comparison to the time you'll spend writing, debugging or maintaining this > code? Yeah, but I wanna!!!!!!! ;-) If you think it's necessary because so many people will be running this > program, then go ahead and do it... however, I'd suggest that you hide > the pointer logic in a srvpgm or module so that at least the programs that > use it don't need to understand the pointer logic. In other words, don't > pass an array to the srvpgm, instead call a getElement() subprocedure to > get element #56 from the array. Or call a getElementByName() subprocedure > that does a lookup based on a value in the array. The calling routines > shouldn't know or care that you used a dynamic array, pointer logic, etc > to implement it. That's not their problem, it's your service program's > problem. Actually, I think this will be an excellent compromise. The gears are moving again. Thanks! Dan
As an Amazon Associate we earn from qualifying purchases.
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.