Re: Speed in Reading

Charles

Your last point is a really good one - not brought up here yet, exactly. Once in memory, and assuming there is enough memory, data is available to all jobs, in any pool. And it is not likely to get paged out. Even if it is, it is likely to be a relatively small part of the data, so faulting should be minimal.

And this applies to data brought in by being read (asynchronously) as opposed to the synchronous load of SETOBJACC. To restate the obvious, with a big enough pool (adequate for both the data and programs, etc.), the effect and benefit might be the same, soon enough, as running SETOBJACC - maybe even better if multiple jobs load different segments of the PF, as discussed in another thread these days. I mean, a synchronous load of 8GB is going to take a while, compared to several jobs loading the data, effectively in parallel.

And, yes, SETOBJACC use does mean reserving a portion of main memory only for the object or objects brung in. I can envision various management issues - maybe have a scheduled job to modify a pool's size for nightly processes that would benefit, then pull back on the size for daily work. Junior-grade automatic performance tool!!!

Off to work!
Vern

On 6/8/2010 7:54 AM, Charles Wilt wrote:

Your thinking is correct.

Loading an 8GB object into memory on a 520 would probably be a bad
idea, on the other hand an 8GB object on a 595 might be just fine.

However, you wouldn't normally load a "transactional" type file into
memory. Normal use of SETOBJACC would be to load "master" files.

On the other hand, say for example an EOD process, whereby you can
reconfigure the pools to provide for lots of memory, it might be
reasonable to load your 8GB inventory transaction file into memory.
But only if it's being used by multiple programs. If for instance,
you've only got one program that processes it in a single pass....then
loading it into memory before hand probably isn't going to help.
Heck, even with multiple programs using the file, you may find that
you'd get better bang for your buck by running the job stream itself
in the pool with the gobs of memory.

Charles


On Tue, Jun 8, 2010 at 8:20 AM, Bryce Martin<BMartin@xxxxxxxxxxxx> wrote:

I like the idea and all, but in this case and others that might be similar
we are talking about putting a large object into a memory pool. Now, I
don't know what you guys consider a large object, and maybe I don't know
enough about memory pools (which is probably the case). But say you need
to process a 'big' file, i'm thinking on that is like 8gigs of data or
something...maybe an inventory transaction file... and you stock that
thing in memory won't you be eating up 8 gigs of your memory from the
system? Is that really a good thing to do?

I really don't know if that is how the memory pool works, but that is the
thought that came to my mind.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



Charles Wilt<charles.wilt@xxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
06/07/2010 05:12 PM
Please respond to
RPG programming on the IBM i / System i<rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the IBM i / System i"<rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Speed in Reading






Your presumption is incorrect...

Read the the first part of the help text...

"An object can be kept main storage resident by selecting a pool for
the object that has available space and does not have jobs associated
with it."

Also, in the document that Kurt provided a link too...
http://www-01.ibm.com/support/docview.wss?uid=nas1dc0a2297bdaefddb86256d6c0069907f


"If a private pool contains only the preloaded data, the data will
stay in memory until the object is explicitly purged (using SETOBJACC
), overlaid with another file as a result of another SETOBJACC (not
recommended), or the pool is cleared by using another new command,
Clear Pool ( CLRPOOL )."

"We recommend using a separate private pool. If you are going to use
the current job's pool, there is no guarantee that the data will stay
in memory. The data is not pinned in memory and can be stolen due to
page fault or other processing that requires storage pool memory. "

HTH,
Charles


On Mon, Jun 7, 2010 at 4:42 PM, Peter Connell
<Peter.Connell@xxxxxxxxxxxxxxxxx> wrote:

My presumption is that always running SETOBJACC prior to accessing the

object in question would do the trick.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



--- This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us and destroy this message immediately. ---
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.