RE: Usage of Indexes and its Effects on an RPG Program

But in this case, since the data has already paged into main storage, you're
no longer seeing the effect of DASD I/O on the buffering of records....  The
operational difference between blocked-sequential I/O and READE is that in
READE, each record is individually fetched from storage.  If that fetch goes
to main storage instead of DASD, it runs nearly as well as
blocked-sequential access.....

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Rich Duzenbury
Sent: Wednesday, December 14, 2005 6:22 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Usage of Indexes and its Effects on an RPG Program


On Wed, 2005-12-14 at 17:55 -0600, DeLong, Eric wrote:
> Rich,
> 
> in order to perform these tests correctly, you should also account for the
> differences between runs where the data is already paged into main
storage.
> Typically, you'd need to CLRPOOL to remove objects before subsequent runs.
> 
Eric,

I thought about doing that, but then I decided that since I can't
dedicate the machine to just this one thing, that it wouldn't make
sense.  

I'm not trying to calculate the absolute performance, just the relative
performance between two methods.

Also, when in production, many of the pages might be in main storage,
and therefore to CLRPOOL could skew results as well.

My strategy is simply to run each routine a number of times and average
the results.  It's crude, but it seems to be effective.  I'm sure there
are cases where one task could 'help' or 'hurt' another, but couldn't
that happen in production as well?

If, on this particular machine, a given task runs in about 15 seconds,
give or take a second every time it runs, I expect it will take 15
seconds next time it runs.  If another takes 30 seconds on average to
run, I expect it will be similar next time, as well.  Thus, I can
conclude that for a given set of records, task2 takes twice as long,
generally, as task1.  

I'm not addressing scaling at all, in that if the number of records are
doubled, perhaps task2 now takes four times as long as task1.

That's probably as good as I can do, but it certainly isn't
statistically valid.