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



I'm only afraid of being proven wrong...

I've always thought there was _no_ cost to extra PRs & CONSTs.

As long as I can show it's an insignificant cost, I'm good. Right now, I
don't understand where/why the cost is coming from.

You might be onto something that the program object is allocated in 4K
chunks...

No to understand what pushed me over the edge to the next 4K...

Obviously, there's a cost to each CONST and PR...question is how much....

I could by trial and error attempt to figure it out...


Charles


On Thu, Mar 16, 2017 at 1:56 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

What are you afraid of?

A programs static size is allocated in chunks of 4K that are paged in from
disk to storage
and reused from storage if not paged out

On Thu, Mar 16, 2017 at 8:32 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Jon,

Not sure what you mean by "what used" information...I'm not aware of
anything in DSPPGM or DSPPGMREF that shows defined consts or prototypes.

Here's some hard numbers...
Program Size Static Storage Size
Basic PGM 77,824 2,640
Include Just PRs 77,824 2,992
Include just CONSTs 77,824 2,640
Include PRs & CONSTs (4KB change?) 81,920 2,992
Include smaller PRs & CONSTs (?) 77,824 2,816

I don't think the CONSTs are wasting space....but I'm curious about
why/when the bump occurs...

Also, since it doesn't appear to be linear...is it just 4KB...or will it
get higher at some point with enough PRs & CONSTs.

The point being I can't say unused PRs & CONSTs take up no space like I
thought I could...

I think I can argue they take up an insignificant amount of space. But
if
someone decides to run their own tests, I need a logical explanation as
to
why 22 PRs and 60 CONSTs take up 4KB.

More importantly, if we keep adding PRs & CONSTs, the number isn't going
to
go up linearly...


Charles



On Thu, Mar 16, 2017 at 10:45 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

Are you sure that what you are seeing is not simply a reflection of an
increase in the "What Used" information stored in the PGM object?

Within the compiler I believe that there's constant folding going on so
that storage is not wasted with multiple names being used for the same
value - so I find it hard to believe that unused constants are
"wasting"
storage.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 16, 2017, at 12:36 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

So I've got a simple RPGLE program...

/FREE
dsply 'Hello World';
*INLR=*ON;
return;
/END-FREE

Compiled with:
OPTION(*NOUNREF) DBGVIEW(*NONE) OPTIMIZE(*FULL) TGTRLS(*CURRENT)

I've also got two /INCLUDE files, one with prototypes and one with
constant
definitions.

I was surprised to find that static storage appears to go up about 16
bytes
per prototype; even though none of the procedures are called.

I was even more surprised to find that program size seems to up 4KB
if
I
include both prototypes & constant files; if I only include one of
them,
it
doesn't change. However, if I cut down the number of PR's &
CONSTs...then
the program size goes back down 4KB.

Can anyone (Barbara :) ) provide some insight into this madness?

I'm trying to argue that this style of using PRs
/define inc_myfun1_pr
/define inc_myfun2_pr
/define inc_myfun3_pr
/include MYPROTOS
/undefine inc_myfun1_pr
/undefine inc_myfun2_pr
/undefine inc_myfun3_pr

To only include the prototypes of procedures you need to call is
silly.

Additionally, I'm arguing for having a STDCONST file of the most used
constants is a good idea. Rather than defining the constants in each
program.

The push-back is that the unneeded PRs & CONSTs would increase
program
size. I said no they won't, but apparently I was wrong. :)

So I'm trying to understand the behavior so I can counter-argue
correctly.

Thanks!
Charles
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


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.