RE: trimming non-numerics

Hans,
 I couldn't agree more, and as you know, I've often said, when asked about
the performance differences between MOVEL and EVAL... "You've already spent
more time thinking about it than you'll ever save in actual CPU time, so
don't worry about it."
But also, I'm in a situation where I have one client who is processing 10s
of millions of records, and sometimes 100s of millions in batch. So every
extra "phempto second" (or how ever you spell that) is important. So if
_MEMCHR is 3 times faster than %SCAN in this context, and I have to send 46
million records through the pipe, I'm going to use _MEMCHR.  But more
importantly, I need to know that _MEMCHR is faster that %scan, and today, I
have to roll my own to do that.
Yes there are still systems out there that are not primarily Internet/Web
based using Interpreted languages, but rather running huge database with
compiled languages, because they need to speed.
-Bob

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Hans Boldt
Sent: Tuesday, June 01, 2004 11:54 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: trimming non-numerics

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

--
This is the RPG programming on the AS400 / iSeries (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.