×
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.
Bob Cozzi wrote:
Hans,
I know you say that often, but what tools/features are available to do
performance testing, or even profiling of a subprocedure? I often have to
insert a timestamp at the start and end of the proc and then write that
value out to the joblog along with the difference. It would be nice to have
something that logged this type of information... even a compiler directive
or option that said "Embed profiling information" then when it is run
(perhaps only when run in debug mode???) the profiling information would be
logged.
-Bob
Bob: As you might have already guessed, performance is a bit of a hot
issue for me.
A Canadian muffler chain used to run ads on TV with a gunslinger
character saying: "First you get good, then you get fast". The same
principle applies to programming. The number one priority is to get your
program running correctly. After other factors like maintainability and
readability, you consider performance. And even then, there's no point
in considering performance unless you think you have a performance
bottleneck.
Consider this: Many CGI applications on the internet run on interpreted
code. Certainly a majority (perhaps even an absolute majority?) of CGI
apps run on Perl, an interpreted language. Ever heard of Google? They
run lots of code written in Python, yet another interpreted language.
And of course we can't leave out Java, still yet another popular
interpreted language. For the webmasters of sites using these
interpreted languages, clearly, performance is not the number one issue.
Over time, CPU's have gotten faster and faster, and so now these days,
the performance penalty of an interpreter is often considered acceptable
relative to the benefits of the particular interpreted language.
OK, now lets say you're an iSeries programmer and you think you have a
performance bottleneck, what do you do? First, check out the offerings
at <http://www-1.ibm.com/servers/eserver/iseries/perfmgmt/>. The first
priority is to identify exactly where the bottlenecks are and fix those.
Most likely, you're looking at issues like database design or system
configuration. At this level, the least likely source of bottleneck is
whether or not %XLATE or %SCAN runs faster.
That said, finally, what's a good way to time the performance of a
particular RPG statement? I normally use a low-tech approach: I save a
timestamp at the beginning and end of a FOR loop containing the
statement under investigation, and subtract the difference in
microseconds. To be a bit more robust, I also usually subtract the time
taken to perform the same FOR loop but with no statements in the loop
body. If there's lots of other activity on the machine, I may run my
test a couple of times to get an average.
I'll end with a few anecdotes from my own experience:
Early on, we did some work on the performance of the RPG IV compiler.
But we quickly came to the conclusion that even if we improved the
front-end speed by 10%, the net effect would be roughly a 3% improvement
since there are (at least) two additional steps to the compilation
process beyond our control. For most programs, that's barely measurable.
That said, I still did some playing around with hash table size in the
RPG IV front-end. Intuitively, I knew that increasing the hash table
size would improve symbol search time. But instead, compilation time
increased! The faster search also had the unfortunate effect of
dramatically increasing the time needed to sort the symbol table after
the parse phase, and I then had to work on improving the sort! (Some
day, I'd still like to revisit that whole symbol table search/sort design!)
The purpose of the last anecdote is to emphasize the importance of
testing when coding for performance.
Cheers! Hans
As an Amazon Associate we earn from qualifying purchases.
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.