Re: [lmi] Dramatic speedup

[Vadim Zeitlin]

On Wed, 19 Sep 2018 14:59:18 +0000 Greg Chicares <address@hidden> wrote:

GC> But consider these startling measurements:
GC> 
GC> milliseconds to produce a PDF illustration
GC>  - using 'all-samples.cns' as shared and recently discussed here
GC>  - "old" = 2018-07-17
GC>  - I threw away the first timing, and report the mean of the next five here

 Did you measure this in a VM or under Wine? Benchmarking in VMs is
notoriously unreliable but I wouldn't think that Wine should affect timings
much.

GC>            HEAD     old   ratio
GC>   gpp       467     846    55%
GC>   ipp       785    1527    51%
GC>   naic      579     ---    ---
GC>   finra     718    1309    55%
GC> 
GC> Your changes applied yesterday made it twice as fast. How did that happen?

 I admit I don't know. I did see speed ups of up to 20% but definitely not
more than that and on average it was less. I could profile this more
carefully if you think it's worth it.

GC> My theory is that source code for an FP language deliberately disregards
GC> efficiency (ostensibly doing the same thing, over and over, each time a
GC> function is called with the same parameters), but compiles into binaries
GC> that are much more efficient than might appear from the source code
GC> (because of runtime memoization); and that your changes applied yesterday,
GC> in moving away from a functional style, effected a memoization (in HTML
GC> parsing as noted above, for example).

 Yes, and this was supposed to make illustration generation faster. I'm
just not sure why do we see such a big difference in the improvement.

GC> Thus, storing intermediate results in C++ class members is like thunking.
GC> We have to do it by hand, in the source. But it makes the source easier
GC> to understand, and the binaries faster.

 Caching/memoizing intermediate results is a performance optimization but
storing things like pdf_writer_wx or illustration pointer as members rather
than passing them around as parameters should have absolutely no effect on
performance, both because an optimizing compiler such as gcc should
generate the same code in both cases and also because even without any
optimizations loading the value from the stack or from the heap can hardly
be a bottleneck (and the former should be microscopically faster, if
anything).

 So if you find even a 8%, let alone 20% or 50% speed gain from avoiding
passing these values as parameters, I'd be really surprised.

 Regards,
VZ