Re: [lmi] Remarkable performance problem

[Greg Chicares]

On 2018-02-28 13:15, Vadim Zeitlin wrote:
> On Wed, 28 Feb 2018 01:54:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--Do you have any idea what I might try next?
> 
>  Assuming that the problem is Wine-specific, which seems reasonable, I
> would try setting WINEDEBUG=warn+all and checking if you see any warnings
> that look like they might be related. If there are too many messages (or,
> on the contrary, if there are no warnings), you might want to replace "all"
> with individual channels, such as "heap" or "seh" (or remove "warn"); see
> https://wiki.winehq.org/Debug_Channels for more information about this.

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

Much of the debug output is uninformative, and I'll want to
suppress it--e.g., I have the impression that using access() to
test whether a file exists, results in a debug message if it
doesn't. Filtering that out manually now:
  <log sed -e'/NtQueryAttributesFile/d' |less -S
I see some routine messages when lmi starts up, like:

warn:keyboard:X11DRV_InitKeyboard vkey 0003 is being used by more than one 
keycode
warn:keyboard:X11DRV_InitKeyboard No more vkeys available!
warn:class:CLASS_RegisterClass Win extra bytes 80 is > 40
warn:msvcrt:msvcrt_init_console :Console handle Initialisation FAILED!
warn:mdi:get_client_info 0x19014a is not an MDI client
warn:font:synthesize_bold_glyph Emboldening format 0x62697473 is not supported

but then when I run the census, I see only:

warn:key:X11DRV_ToUnicodeEx Unknown virtual key 12 !!!
warn:key:X11DRV_ToUnicodeEx Unknown virtual key 11 !!!
warn:key:X11DRV_ToUnicodeEx Unknown virtual key 10 !!!

Some time ago, I routinely ran with some WINEDEBUG options set,
but I stopped doing that (IIRC, when I upgraded to a wine version
that didn't need WINEDEBUG to detect missing DLLs), and now I have
WINEDEBUG unset by default:
  $echo x$WINEDEBUG 
  x
I thought that unsetting it would minimize unwanted overhead,
but now it seems that setting it "fixes" the reported problem
to a large extent.

We want gcc-7 anyway, and to that end I was planning to use a
backport from debian 'testing'. Now I think I should instead
create a 'testing' chroot:

       stable   testing
wine  1.8.7-2     3.0-1
gcc      6.x      7.x

so that, if I see an anomaly in one of two {stable,testing} chroots,
I can try the other chroot.

>  Also, running perf under Linux is always worthwhile -- and very simple to
> do, so I'd also do this and see if you notice anything unusual in its
> output. You could run just the Wine process itself under it or even run it
> system-wide, if your system is reasonably idle, Wine should dominate all
> the statistics anyhow.

I'll look into that later--I'll have to install it first, but
right now $WINEDEBUG seems most promising.

> GC> Today Kim sent me a census file that runs quickly enough for her, but
> GC> shockingly slowly for me. (We can't share it because it contains
> GC> personal information.)
> 
>  Other than it's extremely difficult for me to say anything without being
> able to reproduce the problem myself. Would it be possible to scrub
> personal information from this census somehow and share it with me?

Thanks, I'm working on it.