Re: String Functions

Hi John,

> Here is my test program and some results under
> D5 and D7. The results seem about the same with
> optimization $O+ and $O-.

Two mistakes in your benchmark:

(1) You do not reset the result string (s) back to blank before calling each
function. This means that the SetLength call doesn't do the same thing in
all functions. In fact, after my function the SetLength in yours does
nothing, since the length is already set correctly. Exchange the order of
the calls by putting yours first and you'll see the dramatic difference it
makes. Also, by the time it gets to the thrid test function the memory used
by 's' is cached and it runs much faster.

(2) One iteration is not anywhere near enough. We're talking an execution
time of a few microseconds here.

If I add the line
s := ''
before each benchmark, and I increase the benchmark count to a few thousand
I get repeatable results which bear out the results of my previous post.

Regards,
Pierre


.

Relevant Pages

  • Re: hot path optimizations in uma_zalloc() & uma_zfree()
    ... > around 10% in my test program. ... Buckets are changed when one of them ... > Another optimization is very trivial, ... > if one will decide to commit first optimization, ...
    (freebsd-hackers)
  • Re: ext3 performance inconsistencies, 2.4/2.6
    ... > I don't see any verison numbers mentioned. ... If you want to benchmark ... This is actually _really_ trivial to see with a simple test program. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Interface for Compiler Godegeneration Optimization Modules
    ... I tried a test program too, and failed to get any result. ... I wrote to the author of superoptimizer, Sorav Bansal, telling him ... But the number of possible instructions grows ... optimization passes. ...
    (borland.public.delphi.language.basm)
  • Re: Unexpected results from a mul instruction
    ... optimization on and off wouldn't alter the result? ... compile the test program ... under gcc it works correctly, ... A compiler bug is very believable indeed, I've found a few in my time. ...
    (comp.lang.asm.x86)