|
Just another question: Are you passing these huge variables by VALUE?
If so always a duplicate of the complete maximum length is generated a
populated with the values you pass.
Use CONST instead. When using CONST a duplicate is only generated if the
passed data type or length does not match with the expected data type or
length.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
Im
Auftrag von James Perkins
Gesendet: Friday, 13. November 2009 20:27
An: RPG programming on the IBM i / System i
Betreff: Re: Service Program Overhead
I am using some large variables, but they are varying so I don't think they
should impact performance. My understanding is that varying length strings
don't allocate storage until you tell them how much to allocate, but I
could
be wrong.
That being said, that was why the performance was extremely poor the first
time, hours that is. I had a huge string I was using because I forgot the
lovely varying keyword.
--
James R. Perkins
http://twitter.com/the_jamezp
On Fri, Nov 13, 2009 at 11:07, Dennis Lovelady <iseries@xxxxxxxxxxxx>
wrote:
passingIt seems that the invocation of subprocedures in a service program
significantly slows down performance. I invoke 2 subprocedures on each
write
to the stream file, a replace all subprocedure and the write line
subprocedure. So, for the question, what kind of overhead is there when
invoking subprocedures from a service program? I'm sure there is
information
on this, I just can't seem to find it.
There are lots of ways to impact performance positively and negatively.
Usually when I hear someone complaining about the performance after
modularizing a program, I find that the real issue is that they're
huge variables (rather than pointers to them), and this is a documentedlist
costly technique.
You're not doing that, are you?
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Get your facts first, and then you can distort them as much as you
please."
-- Mark Twain
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
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 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 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.
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.