Re: [lmi] Remarkable performance problem

[Vadim Zeitlin]

On Wed, 28 Feb 2018 17:33:47 +0000 Greg Chicares <address@hidden> wrote:

GC> Well, that's surprising--if I run the problematic census this way:
GC>   $wine ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data
GC> it's as awful as yesterday, of course; but if I do it this way:
GC>   $WINEDEBUG=warn+all wine ./lmi_wx_shared --ash_nazg 
--data_path=/opt/lmi/data >log 2>&1
GC> it zooms through the first couple hundred cells, and simple GUI
GC> operations like PgDown in the census are almost instantaneous.

 Is the effect the same if you use "WINEDEBUG=-all"? I'm not sure how
exactly does this work, but maybe WINEDEBUG has some default value which
slows things down and explicitly setting it overrides it? This seems
unlikely because I don't see why would Wine to choose to be slow by
default, but I have trouble thinking of any other explanations...

GC> I see some routine messages when lmi starts up, like:
[...]
GC> warn:mdi:get_client_info 0x19014a is not an MDI client

 This would seem to indicate a bug in wxWidgets. I wonder if it's possible
to break on the Wine warning function to see where is this one called from?

GC> We want gcc-7 anyway, and to that end I was planning to use a
GC> backport from debian 'testing'. Now I think I should instead
GC> create a 'testing' chroot:
GC> 
GC>        stable   testing
GC> wine  1.8.7-2     3.0-1
GC> gcc      6.x      7.x
GC> 
GC> so that, if I see an anomaly in one of two {stable,testing} chroots,
GC> I can try the other chroot.

 Yes, looks like a good idea (if you want to be more modern, you could try
using containers, but chroot worked just fine for our forbears and still
works fine for me too).

 Good luck,
VZ