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



And if this is a shop standards question, where is the template program that
everyone should use as a base? Any of the three methods of subfile
processing are going to be about the same in performance, but definitely
different in complexity. But, if you have a template program, it's just as
easy to write any of the three.

On Thu, Feb 18, 2010 at 10:52 AM, <Rick.Chevalier@xxxxxxxxxxxxxxx> wrote:

Jerry,

I haven't been following this thread and my intent is not to co-opt the
topic. I do want to respond to your comments about the subfile thread
though to add some clarity.

I agree with you that if the difference is negligible why waste time
worrying about it. The reason I asked the question is that this came up in
a standards committee meeting. As drafted the standard in question states
that the rolling function for subfiles will be handled by the developer in
the program. The real issue isn't to determine how much faster either
method is than the other. Rather, it is, to me anyway, one of making the
developers job easier and helping them be more productive.

Rick

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jerry Adams
Sent: Thursday, February 18, 2010 9:02 AM
To: RPG programming on the IBM i / System i
Subject: RE: "Constant" performance question

Plus isn't it more important that the code be productive from both a
programmer- and user-point-of-view? Unless I find (or have reported to me)
significant issues with performance, I try (not always successfully it turns
out) to write code that (a) the next programmer can most easily decipher
(even though this is a one-man System i-wise shop), and (b) gives the
user/client that easiest path to their objective. Those that dwell upon
nano- or micro-second issues have more important issues that they need to
address.

As an example, the other discussion about subfile performance seems a
little ridiculous to me. On the original AS/400 models there is a
significant difference between page-at-a-time and load-all subfiles. At
least since the Power4 chip the difference is negligible; loading a 1000+
load-all subfile (never had to go the full limit), is still sub-second
response. And, in my opinion, writing a load-all is a heck of a lot easier
to write and understand than a page-at-a-time. Since it's not a programmer
issue, if it ever becomes an issue with the user/client, I would have to
revisit that premise, but a couple of micro seconds is not something I am
going to address.

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


Privileged and Confidential. This e-mail, and any attachments there to, is
intended only for use by the addressee(s) named herein and may contain
privileged or confidential information. If you have received this e-mail in
error, please notify me immediately by a return e-mail and delete this
e-mail. You are hereby notified that any dissemination, distribution or
copying of this e-mail and/or any attachments thereto, is strictly
prohibited.
--
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 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.