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



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

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.