lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Drastic slowdown related to wine upgrade?


From: Greg Chicares
Subject: Re: [lmi] Drastic slowdown related to wine upgrade?
Date: Thu, 31 Jan 2019 13:33:25 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2019-01-28 23:55, Vadim Zeitlin wrote:
> On Fri, 25 Jan 2019 14:13:57 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Since I upgraded from wine-3.x to wine-4.x the other day, the time it 
> takes to
> GC> run this command:
> GC>   time make $coefficiency check_concinnity
> GC>   make $coefficiency check_concinnity  3.50s user 0.98s system 8% cpu 
> 52.817 total
> GC> has grown remarkably, from a few seconds to nearly a minute.

The output of 'apt-get dist-upgrade' is still in my root-terminal
scrollback buffer:

Unpacking fonts-wine (4.0~rc6-1) over (3.0.3-2) ...
Unpacking wine (4.0~rc6-1) over (3.0.3-2) ...
Unpacking wine32:i386 (4.0~rc6-1) over (3.0.3-2) ...
Unpacking wine64 (4.0~rc6-1) over (3.0.3-2) ...
Unpacking libwine:i386 (4.0~rc6-1) over (3.0.3-2) ...
Unpacking libwine:amd64 (4.0~rc6-1) over (3.0.3-2) ...

That was certainly the upgrade event that triggered the reported
slowdown.

Now, your research indicates that the slowdown is observable with
any commands in a pipeline, so it has nothing to do with the
particular pipeline underlying the command I used above...

>  So my minimal reproducible example is that
> 
>       time (wine cmd /c type 'c:\windows\win.ini' >/dev/null)
> 
> takes 0.02s while
> 
>       time (wine cmd /c type 'c:\windows\win.ini' | cat >/dev/null)
> 
> takes 1.2s.
> 
>  If I open the bug with this, which "last good" WINE version should I
> report? I.e. you wrote that you upgraded from wine-3.x, but would you
> remember what was the value of "x"? Was it 3.0.3 from Stretch backports?

As of the moment, that version would be exactly this:
  https://packages.debian.org/stretch-backports/wine
| 3.0.3-2~bpo9+1
and what I formerly had is identified above only as:
  3.0.3-2

Let's see what /var/log/apt/history.log says, omitting other
packages and reporting only 'win32:i386' (other 'wine' subpackages
show the same version numbers):

Start-Date: 2018-11-15  03:23:11
Commandline: apt-get dist-upgrade
wine32:i386 (3.0.2-2, 3.0.3-2)

[...no occurrence of regex /wine/ on any intermediate date...]

Start-Date: 2019-01-24  11:28:29
Commandline: apt-get dist-upgrade
wine32:i386 (3.0.3-2, 4.0~rc6-1)

That doesn't provide any '~' suffix for wine versions, but it
does prove that the '3.0.3-2, 4.0~rc6-1' upgrade is the one
that triggered this slowdown, because it certainly wasn't
evident in November.

The (much) older chroot that I've saved has a much older
version:
  /opt/lmi/src/lmi[0]$wine --version 
  wine-1.8.7 (Debian 1.8.7-2)
which does not exhibit this slowdown. That's the only older
version that I've preserved and can readily retest today.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]