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