Re: [lmi] Dramatic speedup

[Greg Chicares]

On 2018-09-19 15:21, Vadim Zeitlin wrote:
> 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.

Wine.

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

No, not really: we hope to retire XSL-FO soon; the replacement is
probably N times faster, for some value of N not less than two;
and increasing N somewhat at this time isn't likely to affect
perceptions when the new code is released into production.

The benefit that end users will welcome most is the elimination
of a dependency on java, in a treacherously fragile corporate
software ecosystem. That's so important that even doubling the
speed is only a secondary consideration.

But the biggest benefit is that MST can be understood and
maintained where XSL-FO in practice cannot, so speed is really
tertiary: it's just the proverbial icing on the cake.

> 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

Agreed. Yet, OTOH, here's an example from code I'm working on right now:
these two member functions
  page_with_tabular_report::render()
  page_with_tabular_report::get_extra_pages_needed()
both include this statement:
  wx_table_generator table_gen{create_table_generator(ledger, writer)};
so we have two distinct but identical objects. I believe we can assume
that the code that creates them is run twice--so, if we could instead
run it only once and store the result as a data member, that should
save half the work.

That's just an example--I don't know whether avoiding duplication in
this case is conveniently possible.

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

I was really surprised to see that the speed doubled. It was immediately
perceptible even without looking at the status bar's time measurements.
Of course, maybe my hypothesis is wrong, and the actual cause is that
you've doubled the speed of wxHTML or wxPdfDoc.

But the biggest benefit IMO of avoiding a pure functional style is
understandability, so speed is almost secondary. Tertiary, if we
plausibly assume that more-understandable code has fewer defects.