Re: [lmi] PATCH: optimization of view updates in MvcController

[Greg Chicares]

On 2019-06-17 16:38, Vadim Zeitlin wrote:
> On Thu, 13 Jun 2019 18:08:49 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-06-06 20:55, Vadim Zeitlin wrote:
[...]
> GC> >         https://github.com/vadz/lmi/pull/105
[...]
> GC> > which results in big speedup of ConditionallyEnableItems() which is 
> called
> GC> > from every wxEVT_UPDATE_UI event and so is quite performance-critical. 
> How
> GC> > big exactly? Benchmarks show that average time of its execution goes 
> down
> GC> > from 13.1ms to 0.19ms after the first commit, adding the cache for the
> GC> > items of wxItemContainers, and further down to 0.08ms after the second
> GC> > commit optimizing the unnecessary calls to SetStringSelection(), i.e. a
> GC> > ~160x speedup which is really not bad for such a relatively simple 
> patch.
> GC> > If you'd like to redo the benchmarks, you can use
> GC> 
> GC> Instead of just repeating the benchmarks you tested, I thought it might
> GC> be more useful to try some of my own.
> GC> 
> GC> I think what users may notice, even if only subliminally, is the time it
> GC> takes to change from one dialog tab to another, which I measured with the
> GC> patch below[0]. I checked "Enable supplemental report" and observed how
> GC> long it took to switch to and from that page with Ctrl-PgUp and Ctrl-PgDn.
> GC> The timing is coarse, and varies greatly, but overall the patch decreased
> GC> this page-switching time from about forty msec to about thirty-five.
> 
>  This made me suspicious as even though this measurement (which, BTW, I
> agree is more representable of the actual improvement experienced by the
> user) shouldn't show as big gains as the ones I had given, because we
> measured the time taken by just ConditionallyEnableItems() and not the
> entire UponPageChanged(), I'd still expect more. So I've asked Ilya to
> benchmark the time of the page change using your patch under the actual
> native MSW system and the results are indeed quite different from Wine:
> 
> GC> The "Reports" tab has the greatest number of comboboxes; I saw similar
> GC> results with the "Names" tab (which has fewer comboboxes, but many
> GC> items in each).
> 
>  Switching to the "Reports" tab took 150ms before and 2-3ms now. For the
> "Names" tab, the time went down from 60ms to 2ms and for the "Plan" tab, it
> went down from 30ms to 3ms. For all the other pages the changes are inside
> the measurement error, but it's still worth mentioning that the time didn't
> increase for any of them.

Thanks for testing that natively. Timings for these particular tab changes
vary tremendously between native and 'wine'. Millisecond statistics,
before-patch --> after-patch:

wine:
   45 --> 35
msw native:
  150 --> 2 or 3
   60 --> 2

It seems surprising that 'wine' was faster than native before the patch.
I have a Radeon HD 5450, which is like a ten-dollar video card (because
it uses so little electricity that it doesn't get warm even with passive
cooling), so I should see the video performance of 1990s hardware--it
should never beat even a low-end contemporary machine. But maybe this
box is really fast at the C++ data manipulations that have now been
optimized away.

Now, I guess, the video performance dominates (it kind of has to, since
you've removed everything else), and your video is ten or twenty times
as fast as mine--which sounds unsurprising.

Anyway, what's important is that end users will probably see a much
more dramatic effect than I do. That constitutes success.

[...snip my technical wx questions...]

>  So on balance I don't believe there is much to be done here
Agreed. Thanks for explaining.