Re: XML performance issue

John,

I too have hit this kind of problem many times. The two 'obvious' Schlemiel
points are using non-varying strings (in my experience, this one dwarfs all
others) and using multiple instances of e.g. %SUBST or %SCAN and not saving
the result for subsequent similar operations, e.g.:

if %subst( string : 1 : 1 ) = 'A' or
%subst( string : 1 : 1 ) = 'B' or
%subst( string : 1 : 1 ) = 'C';

instead of

char = %subst( string : 1 : 1 );
if char = 'A' or
char = 'B' or
char = 'C';

or even:

char = %subst( string : 1 : 1 );
if %scan( char : 'ABC' ) > 0;

In some cases, the compiler may be able to optimize such things, but it's
not always the case, especially if the operations are spread out through
the code. Obviously one shouldn't necessarily add obscurity simply to
improve performance, but in simplistic cases like the above, it's still
pretty clear what's being done (I'm not trying to start a fight with the
'premature optimization is the root of all evil' Knuth-ites!). Although
obviously this isn't premature - there is a known performance issue.

Speaking of which, I wonder if Åke has tried using different values for the
OPTIMIZE compiler keyword and seen if that provides any benefit?

Rory

On Fri, Sep 14, 2012 at 10:58 AM, John Yeung <gallium.arsenide@xxxxxxxxx>wrote:

On Fri, Sep 14, 2012 at 7:45 AM, Åke Olsson <ake.olsson@xxxxxx> wrote:

As for the XML message creation this is done by regular
string handling, building the MQ message step by step.
I have a hard time finding anything horribly wrong there either.

Actually, I have found that there can be a drastic difference in
performance between different approaches to string handling. You may
be inadvertently using a "Schlemiel" algorithm:

http://en.wikipedia.org/wiki/Schlemiel_the_Painter%27s_algorithm

I can't give you an exact example from RPG at the moment because I'm
out of the office, but I encountered this when I was writing a very
string-intensive RPG program. I remember that initially, how I was
building longer strings was just painfully slow. I tried various
different things until suddenly I got something like a 10-fold speed
increase. I knew at that point I must have just gotten rid of
Schlemiel.

I don't think it's necessarily obvious where Schlemiel is; oftentimes
it's an under-the-covers implementation detail in a high-level
language. We could use a certain HLL construct because it's
conveniently provided for us, but that construct might not be
implemented as efficiently as it could be.

John