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



This project is actually a very good showcase for the power of service programs.

Rewrite the code as a simple RPG IV procedure in a that uses CHAIN
service program...

Now run some tests.

If performance looks to be an issue, you can modify the procedure in
the service program to use an array, user index, ect. without having
to recompile or rebind any programs using it.

Charles


On Wed, Jun 3, 2009 at 2:01 PM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:
Hello,

Is this kind of thing justified? If not, was it ever?

I can't answer that question.  I can almost guarantee that the array
access will be faster.  At the same time, I doubt that you'll notice any
difference.

So, my suggestion is to use a file instead of an array and run it and
see if the performance difference is noticed or not.

As Jon said, this is purely a "pain vs. gain" scenario.  Is it more
painful to maintain the program, or is it more painful to have worse
performance?  My guess is that you won't notice the performance
difference, so maintaining the program is probably more painful.  But
that's a guess.  You are the one who needs to determine that, not me.

The boss is saying that it is not, because repeatedly chaining to the
same record by different calls to the program would mean that the
record would always be available in memory without having to read
from disk. I think that's possible, but no way of knowing for sure.
When the program was written, only 50 records were in the file. Now
there are more than 800.

There are actually (at least) two different factors to consider:

1) whether disk is faster than memory (which the boss has considered)

2) whether access via a keyed database index is faster than an array
lookup (which your boss hasn't considered)

There's no question that memory is faster than disk.  But, as your boss
correctly points out, the system will PROBABLY keep the file in memory,
anyway.  You just can't guarantee that.

However, for the second point, I strongly suspect that array lookups on
a measly 800 records will be DRAMATICALLY faster than keyed lookups will
be.  On 400000 records, however, a linear search of an array might be
slower than a keyed database index (though, I suspect a binary search
would still outperform it).

What the computer has to do to look up a variable in an array is
DRAMATICALLY simpler and requires a lot less CPU than looking up
variables via a database index, even if that index is located in memory.
 Therefore, for a small number of records, I would certainly expect the
array to be faster.  With a binary search, the array lookup will be much
faster.

But all of this is moot.  It doesn't matter which one is faster!  What
matters is whether the easier to maintain solution is /fast enough/.
Who cares if the array is faster if nobody ever notices the difference?
 Do whatever is easier to maintain.  Only if that doesn't perform well
enough to satisfy everyone should you worry about optimizing it.
--
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.