|
Albert:
You don't make it clear what you mean by "accessing". If you need to
read/increment/update something in a user space or data area, you will
want to prevent others from doing so at the "same time". That means
allocating the object. The retrieval from or writing to a data queue does
not use that kind of locking mechanism.
If you use a user space and do NOT need to lock it, your speed depends
upon how often you need to get a pointer to the (data part of) the space.
If it's a "one guy does any updating and many guys read the current
value", then the user space might be your best bet (only one guy needs to
do the ALCOBJ/DLCOBJ). If many guys need to do a read-then-update, you
need to allow time to locate the object for each part of ALCOBJ, Read,
change, DLCOBJ - at least for a DTAARA. For a user space, you may be able
to get a pointer to the space once then do many cycles of ALCOBJ, read,
change, DLCOBJ which will only need to locate the object 2 times instead
of 4.
A data queue will need 2 rounds of "locate the object" but will also need
time to get and/or put a message.
The BEST speed combination if many guys need to ALCOBJ/read/change/DLCOBJ
is probably the user space. I had a requirement to have many jobs doing
just this and I found that the name resolution inherent in the
ALCOBJ/DLCOBJ took 99% of the time if I used a user space and I could keep
the pointer to the space between updates. I was able to use the MI LOCKSL
and UNLOCKSL interfaces (but only in C, not RPGLE) to get a "system
pointer" to the user space and save this pointer between retrieval/update
cycles to save 99% of the time.
That's not for the faint-of-heart but it was most effective.
Dave Schnee,
Barsa Consulting Group, LLC
------------- Albert York wrote ----------
date: Tue, 13 Jun 2006 08:37:47 -0800
from: "Albert York" <albertyork@xxxxxxxxx>
subject: Fastest access: user space, data area, data queue
I was wondering is there is any kind of significant difference in speed
when accessing a user space, data area, or data queue entry.
Thanks,
Albert
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.