Comments on: Performance improvement – RPGLE

By: TomLiotta

TomLiotta — Sat, 08 Dec 2012 01:29:21 +0000

Previously I was only suggesting some actual benchmarks comparing CHAIN with array lookups. I’m almost interested enough to do them myself, but I’m not sure how many variables there are for such test cases. I’d like to believe that an integrated DB2 would be relatively efficient, but…? What OS version is running?

Anyway, I also like the general code structure that is suggested by the snippets we can see, though it’s far from certain. We simply don’t see enough.

For example, get_name, get_ID and get_code are all separate procs. But do they all access separate files? (Are the files global?) Do the secondary files all have the same keys? If any of the files are the same, does each proc still do its own CHAIN? The CHAINs themselves might not be much of a drag if there’s no positioning, but the data movement might be excessive.

It’s understandable to have procs to get values. It’s not so certain that they’re appropriate for this program. If keys match, perhaps a join VIEW or LF might retrieve many values at once into an externally-described DS. That could put code out of the program down into a lower, more efficient level.

Also, are file accesses retrieving entire record formats for PFs with many fields? Or are they LF formats only move the individual fields that are returned by the procs?

How many physical files are accessed? How are they related? How are they indexed? How are VIEWs/LFs defined over them? How many processes are competing for the same resources (files, memory pools, activity levels, whatever)?

In fact, what exactly is the whole point of this program? Reading through 4M records sequentially to update all/many/some/a few seems odd enough. What is business objective for this process?

We don’t know near enough yet. From what I see, a few SQL statements might replace it all, e.g., one UPDATE for case ‘ST’, a second for ‘UR’ and possibly a third for “other”, assuming that VIEWs/INDEXs exist. ut that’s only from “what I see”. There isn’t any visible program logic in what’s been shown to indicate that procedural programming is needed. But we simply don’t see nearly enough. We can’t tell where any bottlenecks might be other than handling too many records, maybe.

Tom

By: philpl1jb

philpl1jb — Fri, 07 Dec 2012 13:50:33 +0000

I love your code…but it’s my understanding that each procedure call takes some extra cycles over subroutines or in-line code…
I’m confident that Tom will straighten me out on that issue.

By: harith

harith — Fri, 07 Dec 2012 13:37:02 +0000

use the CASE stament in Embedded SQL that will update the records at one shot

By: ZWANZIG

ZWANZIG — Fri, 07 Dec 2012 04:54:48 +0000

Hi Philip,
get_name,get_code,get_id all are procedures. each of these procedures use CHAIN operation to retrieve the coresponding value from different files.
Thanks
CV

By: philpl1jb

philpl1jb — Thu, 06 Dec 2012 19:25:12 +0000

What is get_name a field or a function?

By: TomLiotta

TomLiotta — Thu, 06 Dec 2012 10:24:21 +0000

Please find the below code sample.

Good start. All we need now are database definitions, system/environment specs and the rest of the program, and then we can make progress.

Tom

By: ZWANZIG

ZWANZIG — Thu, 06 Dec 2012 08:51:44 +0000

Thanks everyone for your time.
Please find the below code sample. They are reading each and every record and getting the field values through various procedures.
Read Masterfile
Dow Not%EOF
select
when dtatyp = ‘ST’
callp updtefld_ST
when dtatyp = ‘UR’
callp updtefld_UR
other
callp updtefld_other
endsl
Read masterfile
EndDo
updtefld_st – procedure
Eval name = get_name
Eval Id = get_ID
Eval code = get_code—–
—–
—- etc

By: philpl1jb

philpl1jb — Wed, 05 Dec 2012 17:02:01 +0000

Tom
You’re always right, but let me say that I am emotionally incredulous.
and

Incredulity robs us of many pleasures, and gives us nothing in return.

James Russell Lowell

By: TomLiotta

TomLiotta — Tue, 04 Dec 2012 21:00:56 +0000

…moving these into arrays and using lookups instead of chains can improve performatnce…

Does it? I’ve never actually tested. If the files are indeed small, it’s not clear why it would be any faster. An array lookup is essentially the same as an index search. And if the files are small and accessed regularly during the job, they may be brought into the memory pool anyway. (If not, then SETOBJACC can force them to be memory resident without changing the program logic.)

DB2 system-level code is reasonably efficient. It might be more efficient than coded program logic… if the database is appropriately designed. The design might be the biggest issue. Could be an interesting test.

Tom

By: ToddN2000

ToddN2000 — Tue, 04 Dec 2012 16:25:50 +0000

If you are using any SETLL, READE, DOW or DOU check to seek if your key can be modified to cut down the number of I/O’s being done. For example if the current code does a SETLL then READE on CUST# you may want to expand it to CUST#, DIVISION… You may need a few new logicals but it should help with performance.