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

Follow-Ups:
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.