Re: Performance problems with emacs-X11 in current cygwin

Re: Performance problems with emacs-X11 in current cygwin

[Angelo Graziosi]

Ken Brown wrote:

> Yes, that is a lot of packages (almost 200). I don't think that will be of any help in pinning down the problem.

My upgrade regarded these packages:

_autorebase-000069-1.tar.bz2
_update-info-dir-01051-1.tar.bz2
fftw3-3.3.2-1.tar.bz2
glib2.0-networking-2.32.3-1.tar.bz2
gsettings-desktop-schemas-3.4.2-1.tar.bz2
gtk3-demo-3.4.3-1.tar.bz2
gvfs-1.12.3-1.tar.bz2
libfftw3-devel-3.3.2-1.tar.bz2
libfftw3_3-3.3.2-1.tar.bz2
libglib2.0-devel-2.32.3-1.tar.bz2
libglib2.0_0-2.32.3-1.tar.bz2
libgtk3-devel-3.4.3-1.tar.bz2
libgtk3_0-3.4.3-1.tar.bz2
libsasl2-2.1.25-1.tar.bz2
libsasl2-devel/libsasl2-devel-2.1.25-1.tar.bz2
libssh2-devel/libssh2-devel-1.4.2-1.tar.bz2
libssh2_1-1.4.2-1.tar.bz2
xterm-279-1.tar.bz2

I suspect gvfs, gtk3, libglib2... but I can't downgrade anything.

Ciao,
Angelo.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin (attn: glib and gvim maintainer)

[Ken Brown]

On 5/31/2012 4:51 PM, Angelo Graziosi wrote:
> My upgrade regarded these packages:
>
> _autorebase-000069-1.tar.bz2
> _update-info-dir-01051-1.tar.bz2
> fftw3-3.3.2-1.tar.bz2
> glib2.0-networking-2.32.3-1.tar.bz2
> gsettings-desktop-schemas-3.4.2-1.tar.bz2
> gtk3-demo-3.4.3-1.tar.bz2
> gvfs-1.12.3-1.tar.bz2
> libfftw3-devel-3.3.2-1.tar.bz2
> libfftw3_3-3.3.2-1.tar.bz2
> libglib2.0-devel-2.32.3-1.tar.bz2
> libglib2.0_0-2.32.3-1.tar.bz2
> libgtk3-devel-3.4.3-1.tar.bz2
> libgtk3_0-3.4.3-1.tar.bz2
> libsasl2-2.1.25-1.tar.bz2
> libsasl2-devel/libsasl2-devel-2.1.25-1.tar.bz2
> libssh2-devel/libssh2-devel-1.4.2-1.tar.bz2
> libssh2_1-1.4.2-1.tar.bz2
> xterm-279-1.tar.bz2
>
> I suspect gvfs, gtk3, libglib2... but I can't downgrade anything.

I found an XP system that hadn't been upgraded in a few weeks, and I 
upgraded libglib2.0_0 but nothing else.  This was enough to trigger the 
problem.  I can reliably reproduce it as follows:

1. Start the X server (on an XP system) via the Start Menu shortcut.

2. Install emacs-X11-23.4-2, and start emacs under X.

3. Type 'C-x b RET' to switch to the *scratch* buffer.

4. Press and hold one key.  It echoes once, but the "repeated" key 
strokes don't get echoed until you release the key.

Fortunately for emacs users, the problem doesn't seem to occur with 
emacs-24.  (Can anyone else confirm this?)  But that doesn't help the 
gvim users who have reported similar problems.

Yaakov, could you take a look?  Maybe you could also make the previous 
version of libglib2.0_0 available so that users can downgrade until this 
gets resolved.

BTW, I installed the latest Cygwin snapshot, but that didn't help.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin (attn: glib and gvim maintainer)

[atelp]

Hello,

Sorry, I have the same issue with emacs24 (GNU Emacs 24.0.96.1
(i686-pc-cygwin, GTK+ Version 2.24.10)).
Well it seems this EMACS 24 is built with GTK2.

This is the emacs package 24.0.96-2  I installed with setup.exe.

Regards
Fabien

On Fri, Jun 1, 2012 at 1:00 PM, Ken Brown <kbrown@cornell.edu> wrote:
>
> On 5/31/2012 4:51 PM, Angelo Graziosi wrote:
>>
>> My upgrade regarded these packages:
>>
>> _autorebase-000069-1.tar.bz2
>> _update-info-dir-01051-1.tar.bz2
>> fftw3-3.3.2-1.tar.bz2
>> glib2.0-networking-2.32.3-1.tar.bz2
>> gsettings-desktop-schemas-3.4.2-1.tar.bz2
>> gtk3-demo-3.4.3-1.tar.bz2
>> gvfs-1.12.3-1.tar.bz2
>> libfftw3-devel-3.3.2-1.tar.bz2
>> libfftw3_3-3.3.2-1.tar.bz2
>> libglib2.0-devel-2.32.3-1.tar.bz2
>> libglib2.0_0-2.32.3-1.tar.bz2
>> libgtk3-devel-3.4.3-1.tar.bz2
>> libgtk3_0-3.4.3-1.tar.bz2
>> libsasl2-2.1.25-1.tar.bz2
>> libsasl2-devel/libsasl2-devel-2.1.25-1.tar.bz2
>> libssh2-devel/libssh2-devel-1.4.2-1.tar.bz2
>> libssh2_1-1.4.2-1.tar.bz2
>> xterm-279-1.tar.bz2
>>
>> I suspect gvfs, gtk3, libglib2... but I can't downgrade anything.
>
>
> I found an XP system that hadn't been upgraded in a few weeks, and I
> upgraded libglib2.0_0 but nothing else.  This was enough to trigger the
> problem.  I can reliably reproduce it as follows:
>
> 1. Start the X server (on an XP system) via the Start Menu shortcut.
>
> 2. Install emacs-X11-23.4-2, and start emacs under X.
>
> 3. Type 'C-x b RET' to switch to the *scratch* buffer.
>
> 4. Press and hold one key.  It echoes once, but the "repeated" key strokes
> don't get echoed until you release the key.
>
> Fortunately for emacs users, the problem doesn't seem to occur with
> emacs-24.  (Can anyone else confirm this?)  But that doesn't help the gvim
> users who have reported similar problems.
>
> Yaakov, could you take a look?  Maybe you could also make the previous
> version of libglib2.0_0 available so that users can downgrade until this
> gets resolved.
>
> BTW, I installed the latest Cygwin snapshot, but that didn't help.
>
> Ken
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin (attn: glib and gvim maintainer)

[Ken Brown]

[Reformatted.  Please don't top-post.]

On 6/1/2012 7:20 AM, xxx@xxx wrote:
> On Fri, Jun 1, 2012 at 1:00 PM, Ken Brown<kbrown@cornell.edu>  wrote:
>>
>> On 5/31/2012 4:51 PM, Angelo Graziosi wrote:
>>>
>>> My upgrade regarded these packages:
>>>
>>> _autorebase-000069-1.tar.bz2
>>> _update-info-dir-01051-1.tar.bz2
>>> fftw3-3.3.2-1.tar.bz2
>>> glib2.0-networking-2.32.3-1.tar.bz2
>>> gsettings-desktop-schemas-3.4.2-1.tar.bz2
>>> gtk3-demo-3.4.3-1.tar.bz2
>>> gvfs-1.12.3-1.tar.bz2
>>> libfftw3-devel-3.3.2-1.tar.bz2
>>> libfftw3_3-3.3.2-1.tar.bz2
>>> libglib2.0-devel-2.32.3-1.tar.bz2
>>> libglib2.0_0-2.32.3-1.tar.bz2
>>> libgtk3-devel-3.4.3-1.tar.bz2
>>> libgtk3_0-3.4.3-1.tar.bz2
>>> libsasl2-2.1.25-1.tar.bz2
>>> libsasl2-devel/libsasl2-devel-2.1.25-1.tar.bz2
>>> libssh2-devel/libssh2-devel-1.4.2-1.tar.bz2
>>> libssh2_1-1.4.2-1.tar.bz2
>>> xterm-279-1.tar.bz2
>>>
>>> I suspect gvfs, gtk3, libglib2... but I can't downgrade anything.
>>
>>
>> I found an XP system that hadn't been upgraded in a few weeks, and I
>> upgraded libglib2.0_0 but nothing else.  This was enough to trigger the
>> problem.  I can reliably reproduce it as follows:
>>
>> 1. Start the X server (on an XP system) via the Start Menu shortcut.
>>
>> 2. Install emacs-X11-23.4-2, and start emacs under X.
>>
>> 3. Type 'C-x b RET' to switch to the *scratch* buffer.
>>
>> 4. Press and hold one key.  It echoes once, but the "repeated" key strokes
>> don't get echoed until you release the key.
>>
>> Fortunately for emacs users, the problem doesn't seem to occur with
>> emacs-24.  (Can anyone else confirm this?)  But that doesn't help the gvim
>> users who have reported similar problems.
>>
>> Yaakov, could you take a look?  Maybe you could also make the previous
>> version of libglib2.0_0 available so that users can downgrade until this
>> gets resolved.
 > Sorry, I have the same issue with emacs24

You're right, I spoke too soon.  But the problem is definitely not as 
bad on my XP system with emacs-24.  Now when I press and hold a key, it 
gets echoed in chunks, a few characters at a time.  I don't have to wait 
until I release the key before seeing the characters.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin (attn: glib and gvim maintainer)

[Stephen L]

Ken Brown <kbrown <at> cornell.edu> writes:
> Fortunately for emacs users, the problem doesn't seem to occur with 
> emacs-24.  (Can anyone else confirm this?)

Hi Ken,

So I just upgraded to emacs-24 (24.0.96.1), and while it is certainly better, I
wouldn't say it's fixed.

Try opening a text file (I have a ~1000 line piece code).

If you mouse around in the X window, and left click, the emacs cursor is
sluggish to move.

In fact it appears the more mouse movement between clicks, the more sluggish
emacs is to respond.

Something not consuming PointerMotionMask events, perhaps?

best regards,
stephen

(edit to add: the gmane web interface has just given me "moron" as my captcha,
that is awesome!)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin (attn: glib and gvim maintainer)

[Ken Brown]

On 6/1/2012 7:00 AM, Ken Brown wrote:
> I found an XP system that hadn't been upgraded in a few weeks, and I
> upgraded libglib2.0_0 but nothing else. This was enough to trigger the
> problem.

I've checked the git repository for glib at

   http://git.gnome.org/browse/glib/log/?h=glib-2-32

and there were very few changes between 2.32.2 and 2.32.3.  The only one 
that looks to me like it could have anything to do with our problem is 
the 2012-05-14 change to GConverterInputStream.  The change appears to 
be a pretty obvious bug fix, but I can imagine a scenario in which 
fixing the bug would result in the symptoms we're seeing.

I'm not going to speculate further until I can get access to an XP 
system to do some testing.  Or maybe someone who uses XP regularly will 
beat me to it.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin (attn: glib and gvim maintainer)

[K Stahl]

This morning, I reverted GLib2.0 to a previous version and it did not
solve the issue.

Steps used in testing:
Extracted "libglib2.0_0-2.30.2-1.tar.bz2" and ran /etc/postinstall/glib2.0.sh
Started XWin and attempted to edit a file via gvim (performance issue
still remain)

On Fri, Jun 1, 2012 at 2:39 PM, Ken Brown <kbrown@cornell.edu> wrote:
> On 6/1/2012 7:00 AM, Ken Brown wrote:
>>
>> I found an XP system that hadn't been upgraded in a few weeks, and I
>> upgraded libglib2.0_0 but nothing else. This was enough to trigger the
>> problem.
>
>
> I've checked the git repository for glib at
>
>  http://git.gnome.org/browse/glib/log/?h=glib-2-32
>
> and there were very few changes between 2.32.2 and 2.32.3.  The only one
> that looks to me like it could have anything to do with our problem is the
> 2012-05-14 change to GConverterInputStream.  The change appears to be a
> pretty obvious bug fix, but I can imagine a scenario in which fixing the bug
> would result in the symptoms we're seeing.
>
> I'm not going to speculate further until I can get access to an XP system to
> do some testing.  Or maybe someone who uses XP regularly will beat me to it.
>
>
> Ken
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Angelo Graziosi]

Ken,

Ken Brown wrote:

> Is this on XP? I ask because I'm having trouble reverting my XP system back to a state where there's no problem.

I think we cannot revert because many of "prev" packages have been 
removed by Cygwin distro.

Anyway, I have only XP and Emacs 24 from trunk, and it cannot be used so 
as it stands... :-(

Ciao,
Angelo.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/2/2012 10:15 AM, Angelo Graziosi wrote:
> Ken,
>
> Ken Brown wrote:
>
>> Is this on XP? I ask because I'm having trouble reverting my XP system
>> back to a state where there's no problem.
>
> I think we cannot revert because many of "prev" packages have been
> removed by Cygwin distro.

We can revert by using the CTM (Cygwin Time Machine):

   http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine

I'm hoping to do that this weekend on my XP machine and see if I can pin 
down when the problem started.  I made some incorrect statements about 
that earlier in the thread.

The problem was first reported on the list on May 11:

   http://cygwin.com/ml/cygwin-xfree/2012-05/msg00007.html ,

and the poster said he had updated on May 10.  This is the day it was 
announced that the GNOME libraries were updated to 3.4.1 and that cygwin 
was updated to 1.7.15.

The CTM has a snapshot dated 2012-05-08, which is probably a good place 
to start.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/2/2012 11:09 AM, Ken Brown wrote:
> We can revert by using the CTM (Cygwin Time Machine):
>
> http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine
>
> I'm hoping to do that this weekend on my XP machine and see if I can pin
> down when the problem started. I made some incorrect statements about
> that earlier in the thread.
>
> The problem was first reported on the list on May 11:
>
> http://cygwin.com/ml/cygwin-xfree/2012-05/msg00007.html ,
>
> and the poster said he had updated on May 10. This is the day it was
> announced that the GNOME libraries were updated to 3.4.1 and that cygwin
> was updated to 1.7.15.
>
> The CTM has a snapshot dated 2012-05-08, which is probably a good place
> to start.

That worked for me.  I reverted all GNOME components to the versions in 
that CTM snapshot, and then I upgraded them one at a time until the 
emacs problem appeared.  This happened when I upgraded libglib2.0_0 from 
2.30.2-1 to 2.32.2-1, so I downgraded it again.  I also had to keep the 
following old versions:

   libgtk2.0_0-2.24.10-1
   libgdk_pixbuf2.0_0-2.24.1-1
   libpango1.0_0-1.29.4-2

When I tried to upgrade any of those, emacs would immediately exit with 
error 127.  I guess they rely on features of the newer libglib.  All of 
my other packages are up to date, and I can't detect any problems with 
emacs-X11-23.4-2 or emacs-X11-24.0.96-2.

I'm trying to keep a fairly minimal set of packages installed on my XP 
system, so other people may find that they have additional packages that 
need to be downgraded to work around this problem.

I hope someone (Yaakov?) will take a look at the glib changes between 
2.30.2 and 2.32.2 and try to find the cause of this problem.

I don't use gvim, so I don't know whether the same downgrades will help 
with the gvim problem.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Yaakov (Cygwin/X)]

On 2012-06-02 14:02, Ken Brown wrote:
> I hope someone (Yaakov?) will take a look at the glib changes between
> 2.30.2 and 2.32.2 and try to find the cause of this problem.

I keep seeing XP in this thread.  If this is affecting only XP and not 
other versions of Windows, then it would be a bug in either Cygwin or 
xorg-server, not glib.  I, for one, do not have XP handy.


Yaakov

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/3/2012 5:08 AM, Yaakov (Cygwin/X) wrote:
> On 2012-06-02 14:02, Ken Brown wrote:
>> I hope someone (Yaakov?) will take a look at the glib changes between
>> 2.30.2 and 2.32.2 and try to find the cause of this problem.
>
> I keep seeing XP in this thread. If this is affecting only XP and not
> other versions of Windows, then it would be a bug in either Cygwin or
> xorg-server, not glib. I, for one, do not have XP handy.

It happens on XP but not Windows 7.  I don't know about other versions.

I wasn't suggesting that this is necessarily a glib bug, just that some 
change in glib triggered the problem.  If we could pin down which change 
that was, it would be easier to get the bug fixed, wherever it is.

I'll try to do some bisection as I have time.  But you're familiar with 
glib and I'm not, so maybe you could look over the changes and see if 
you spot anything suspicious.  Also, I'm confused about the various 
branches that I see in the git repository.  There seems to be current 
development on the 2-30 branch, the 2-31 branch, and the 2-32 branch. 
If I find that the problem still exists at the beginning of the 2-32 
branch, how do I go backwards from there?

I've also never worked with git before, so I'd appreciate some advice 
(or a cygport file?) that would help with the bisection.

Thanks.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/3/2012 8:10 AM, Ken Brown wrote:
> On 6/3/2012 5:08 AM, Yaakov (Cygwin/X) wrote:
>> On 2012-06-02 14:02, Ken Brown wrote:
>>> I hope someone (Yaakov?) will take a look at the glib changes between
>>> 2.30.2 and 2.32.2 and try to find the cause of this problem.
>>
>> I keep seeing XP in this thread. If this is affecting only XP and not
>> other versions of Windows, then it would be a bug in either Cygwin or
>> xorg-server, not glib. I, for one, do not have XP handy.
>
> It happens on XP but not Windows 7. I don't know about other versions.
>
> I wasn't suggesting that this is necessarily a glib bug, just that some
> change in glib triggered the problem. If we could pin down which change
> that was, it would be easier to get the bug fixed, wherever it is.
>
> I'll try to do some bisection as I have time. But you're familiar with
> glib and I'm not, so maybe you could look over the changes and see if
> you spot anything suspicious. Also, I'm confused about the various
> branches that I see in the git repository. There seems to be current
> development on the 2-30 branch, the 2-31 branch, and the 2-32 branch. If
> I find that the problem still exists at the beginning of the 2-32
> branch, how do I go backwards from there?
>
> I've also never worked with git before, so I'd appreciate some advice
> (or a cygport file?) that would help with the bisection.

Never mind.  I'm not up to this task.  But if you're willing to 
facilitate the bisection by doing the builds, I'll be glad to test them 
on my XP system, at least as far as emacs is concerned.  And I'm sure 
there are gvim users who would do the same.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Stephen L]

Ken Brown <kbrown <at> cornell.edu> writes:
> Never mind.  I'm not up to this task.  But if you're willing to 
> facilitate the bisection by doing the builds, I'll be glad to test them 
> on my XP system, at least as far as emacs is concerned.  And I'm sure 
> there are gvim users who would do the same.

ok so I've been looking through the glib repo, there's not a huge amount of
obvious changes, but this one looks interesting:

http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=b1d447bd664bcbc607811c7920b67856d4f551e6

it will take me a few days to find the time, but I will make an effort to bisect
this a little further. watch this space

best regards,
stephen



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/6/2012 7:04 AM, Stephen L wrote:
> Ken Brown<kbrown<at>  cornell.edu>  writes:
>> Never mind.  I'm not up to this task.  But if you're willing to
>> facilitate the bisection by doing the builds, I'll be glad to test them
>> on my XP system, at least as far as emacs is concerned.  And I'm sure
>> there are gvim users who would do the same.
>
> ok so I've been looking through the glib repo, there's not a huge amount of
> obvious changes, but this one looks interesting:
>
> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=b1d447bd664bcbc607811c7920b67856d4f551e6
>
> it will take me a few days to find the time, but I will make an effort to bisect
> this a little further. watch this space

So that you don't go on a wild goose chase, I've been testing released 
version of glib from http://ftp.gnome.org/pub/gnome/sources/glib, and 
I've determined that the problem does not occur with glib-2.30.3 but 
does occur with glib-2.31.0.

As I said earlier, I don't understand very well how git branches work, 
but I *think* this means we have to look in the 2-32 branch, prior to 
the 2.31.0 tag, to find the problematic commit.  I've checked out the 
2-32 branch, and I guess the next step is to find a problem-free 
revision of that branch, and then bisect between it and the 2.31.0 tag. 
  I'm in the process of reading the git documentation to figure out how 
to do that, but I wouldn't object if someone would save me some time by 
giving me the appropriate git commands.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Achim Gratz]

Ken Brown writes:
> As I said earlier, I don't understand very well how git branches work,
> but I *think* this means we have to look in the 2-32 branch, prior to
> the 2.31.0 tag, to find the problematic commit.  I've checked out the
> 2-32 branch, and I guess the next step is to find a problem-free
> revision of that branch, and then bisect between it and the 2.31.0
> tag. I'm in the process of reading the git documentation to figure out
> how to do that, but I wouldn't object if someone would save me some
> time by giving me the appropriate git commands.

I've had a quick look at how the GNOME folks use their release branches:
they are tagged in master and then only some version bumping and a few
quickfixes.  There are no odd numbered releases, so I assume they start
the disruptive changes right after a release, tag the unstable version
in master with an odd number and then work out the kinks until the new
release is done.

So, you can indeed start on the 2.32 branch and then bisect down to the
2.30 tag.  Don't bother with the run-up between 2.31 and 2.32, just
bisect it whole, the bisect sequence will be just one build longer if at
all.

git checkout glib-2-32
git bisect start bad
git bisect good 2.30.3

If any of the intermediate versions doesn't build, say

git bisect skip

with the offending commit still checked out.


HTH,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/8/2012 11:33 AM, Achim Gratz wrote:
> Ken Brown writes:
>> As I said earlier, I don't understand very well how git branches work,
>> but I *think* this means we have to look in the 2-32 branch, prior to
>> the 2.31.0 tag, to find the problematic commit.  I've checked out the
>> 2-32 branch, and I guess the next step is to find a problem-free
>> revision of that branch, and then bisect between it and the 2.31.0
>> tag. I'm in the process of reading the git documentation to figure out
>> how to do that, but I wouldn't object if someone would save me some
>> time by giving me the appropriate git commands.
>
> I've had a quick look at how the GNOME folks use their release branches:
> they are tagged in master and then only some version bumping and a few
> quickfixes.  There are no odd numbered releases, so I assume they start
> the disruptive changes right after a release, tag the unstable version
> in master with an odd number and then work out the kinks until the new
> release is done.
>
> So, you can indeed start on the 2.32 branch and then bisect down to the
> 2.30 tag.  Don't bother with the run-up between 2.31 and 2.32, just
> bisect it whole, the bisect sequence will be just one build longer if at
> all.
>
> git checkout glib-2-32
> git bisect start bad
> git bisect good 2.30.3
>
> If any of the intermediate versions doesn't build, say
>
> git bisect skip
>
> with the offending commit still checked out.

Thanks, Achim.  That helps a lot.  The only thing I might have to change 
is the starting point for the bisection, since the tag 2.30.3 represents 
a fairly recent commit.  But I think starting with 2.30.1 should work. 
I'll give it a try.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Andrey Repin]

Greetings, Ken Brown!

> Thanks, Achim.  That helps a lot.  The only thing I might have to change
> is the starting point for the bisection, since the tag 2.30.3 represents 
> a fairly recent commit.  But I think starting with 2.30.1 should work. 
> I'll give it a try.

Why not slice relevant branch by commit dates, then?


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 08.06.2012, <23:34>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/8/2012 12:45 PM, Ken Brown wrote:
> On 6/8/2012 11:33 AM, Achim Gratz wrote:
>> Ken Brown writes:
>>> As I said earlier, I don't understand very well how git branches work,
>>> but I *think* this means we have to look in the 2-32 branch, prior to
>>> the 2.31.0 tag, to find the problematic commit. I've checked out the
>>> 2-32 branch, and I guess the next step is to find a problem-free
>>> revision of that branch, and then bisect between it and the 2.31.0
>>> tag. I'm in the process of reading the git documentation to figure out
>>> how to do that, but I wouldn't object if someone would save me some
>>> time by giving me the appropriate git commands.
>>
>> I've had a quick look at how the GNOME folks use their release branches:
>> they are tagged in master and then only some version bumping and a few
>> quickfixes. There are no odd numbered releases, so I assume they start
>> the disruptive changes right after a release, tag the unstable version
>> in master with an odd number and then work out the kinks until the new
>> release is done.
>>
>> So, you can indeed start on the 2.32 branch and then bisect down to the
>> 2.30 tag. Don't bother with the run-up between 2.31 and 2.32, just
>> bisect it whole, the bisect sequence will be just one build longer if at
>> all.
>>
>> git checkout glib-2-32
>> git bisect start bad
>> git bisect good 2.30.3
>>
>> If any of the intermediate versions doesn't build, say
>>
>> git bisect skip
>>
>> with the offending commit still checked out.
>
> Thanks, Achim. That helps a lot. The only thing I might have to change
> is the starting point for the bisection, since the tag 2.30.3 represents
> a fairly recent commit. But I think starting with 2.30.1 should work.
> I'll give it a try.

The bisection shows that the first problematic commit is this one:

http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79

Author: Ryan Lortie <desrt@desrt.ca>
Date:   Wed Aug 31 22:07:02 2011 -0400

     GMain: simplify logic for g_wakeup_acknowledge()

     Instead of messing around with context->poll_waiting, just look at 
the GPollFD to see if the GWakeup needs to be acknowledged.

In case anyone else wants to confirm this, you can get my glib builds by 
running

   setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg

and adding http://sanibeltranquility.com/cygwin to the list of mirrors. 
  The problematic version is

   libglib2.0_0-2.30.90_7eae4861-1

and the preceding version (without the problem) is

   libglib2.0_0-2.30.90_87880df-1

I've tested the latter with emacs-23, emacs-24, and gvim.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Yaakov (Cygwin/X)]

On 2012-06-10 19:45, Ken Brown wrote:
> The bisection shows that the first problematic commit is this one:
>
> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>
>
> Author: Ryan Lortie <desrt@desrt.ca>
> Date: Wed Aug 31 22:07:02 2011 -0400
>
> GMain: simplify logic for g_wakeup_acknowledge()
>
> Instead of messing around with context->poll_waiting, just look at the
> GPollFD to see if the GWakeup needs to be acknowledged.
>
> In case anyone else wants to confirm this, you can get my glib builds by
> running
>
> setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg
>
> and adding http://sanibeltranquility.com/cygwin to the list of mirrors.
> The problematic version is
>
> libglib2.0_0-2.30.90_7eae4861-1
>
> and the preceding version (without the problem) is
>
> libglib2.0_0-2.30.90_87880df-1
>
> I've tested the latter with emacs-23, emacs-24, and gvim.

Thanks for doing this.  Is this still only a problem with XP?  If so, it 
is most likely a bug in Cygwin itself.


Yaakov

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
> On 2012-06-10 19:45, Ken Brown wrote:
>> The bisection shows that the first problematic commit is this one:
>>
>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>>
>>
>>
>> Author: Ryan Lortie <desrt@desrt.ca>
>> Date: Wed Aug 31 22:07:02 2011 -0400
>>
>> GMain: simplify logic for g_wakeup_acknowledge()
>>
>> Instead of messing around with context->poll_waiting, just look at the
>> GPollFD to see if the GWakeup needs to be acknowledged.
>>
>> In case anyone else wants to confirm this, you can get my glib builds by
>> running
>>
>> setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg
>>
>> and adding http://sanibeltranquility.com/cygwin to the list of mirrors.
>> The problematic version is
>>
>> libglib2.0_0-2.30.90_7eae4861-1
>>
>> and the preceding version (without the problem) is
>>
>> libglib2.0_0-2.30.90_87880df-1
>>
>> I've tested the latter with emacs-23, emacs-24, and gvim.
>
> Thanks for doing this. Is this still only a problem with XP? If so, it
> is most likely a bug in Cygwin itself.

It's a problem with XP but not with Windows 7.  No one has reported 
testing other systems.

Do you understand the code well enough to make a test case to help cgf 
and Corinna debug it, assuming it's a Cygwin bug?

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[K Stahl]

I've tried to revert the version of GLib 2.0 using the instructions
provided, but when I attempt to start GVim nothing happens.  The
process appears to fail without an explanation.  System WinXP and all
Cygwin libs updated to the latest.

On Sun, Jun 10, 2012 at 8:45 PM, Ken Brown <kbrown@cornell.edu> wrote:
> On 6/8/2012 12:45 PM, Ken Brown wrote:
>>
>> On 6/8/2012 11:33 AM, Achim Gratz wrote:
>>>
>>> Ken Brown writes:
>>>>
>>>> As I said earlier, I don't understand very well how git branches work,
>>>> but I *think* this means we have to look in the 2-32 branch, prior to
>>>> the 2.31.0 tag, to find the problematic commit. I've checked out the
>>>> 2-32 branch, and I guess the next step is to find a problem-free
>>>> revision of that branch, and then bisect between it and the 2.31.0
>>>> tag. I'm in the process of reading the git documentation to figure out
>>>> how to do that, but I wouldn't object if someone would save me some
>>>> time by giving me the appropriate git commands.
>>>
>>>
>>> I've had a quick look at how the GNOME folks use their release branches:
>>> they are tagged in master and then only some version bumping and a few
>>> quickfixes. There are no odd numbered releases, so I assume they start
>>> the disruptive changes right after a release, tag the unstable version
>>> in master with an odd number and then work out the kinks until the new
>>> release is done.
>>>
>>> So, you can indeed start on the 2.32 branch and then bisect down to the
>>> 2.30 tag. Don't bother with the run-up between 2.31 and 2.32, just
>>> bisect it whole, the bisect sequence will be just one build longer if at
>>> all.
>>>
>>> git checkout glib-2-32
>>> git bisect start bad
>>> git bisect good 2.30.3
>>>
>>> If any of the intermediate versions doesn't build, say
>>>
>>> git bisect skip
>>>
>>> with the offending commit still checked out.
>>
>>
>> Thanks, Achim. That helps a lot. The only thing I might have to change
>> is the starting point for the bisection, since the tag 2.30.3 represents
>> a fairly recent commit. But I think starting with 2.30.1 should work.
>> I'll give it a try.
>
>
> The bisection shows that the first problematic commit is this one:
>
> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>
> Author: Ryan Lortie <desrt@desrt.ca>
> Date:   Wed Aug 31 22:07:02 2011 -0400
>
>    GMain: simplify logic for g_wakeup_acknowledge()
>
>    Instead of messing around with context->poll_waiting, just look at the
> GPollFD to see if the GWakeup needs to be acknowledged.
>
> In case anyone else wants to confirm this, you can get my glib builds by
> running
>
>  setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg
>
> and adding http://sanibeltranquility.com/cygwin to the list of mirrors.  The
> problematic version is
>
>  libglib2.0_0-2.30.90_7eae4861-1
>
> and the preceding version (without the problem) is
>
>  libglib2.0_0-2.30.90_87880df-1
>
> I've tested the latter with emacs-23, emacs-24, and gvim.
>
>
> Ken
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

Please don't http://cygwin.com/acronyms/#TOFU .  Thanks.

On 6/11/2012 9:55 AM, K Stahl wrote:
> I've tried to revert the version of GLib 2.0 using the instructions
> provided, but when I attempt to start GVim nothing happens.  The
> process appears to fail without an explanation.  System WinXP and all
> Cygwin libs updated to the latest.

Did you also downgrade to

   libgtk2.0_0-2.24.10-1
   libgdk_pixbuf2.0_0-2.24.1-1
   libpango1.0_0-1.29.4-2

as explained in http://cygwin.com/ml/cygwin/2012-06/msg00043.html? 
There are two possible ways to do that:

1. If you still have those packages in your download directory, you can 
run setup.exe and choose "Install from Local Directory".

2. Otherwise, you can get them from the Cygwin Time Machine by running 
'setup.exe -X' and adding 
ftp://www.fruitbat.org/pub/cygwin/circa/2012/05/08/111042 to the list of 
mirrors.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/11/2012 7:39 AM, Ken Brown wrote:
> On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
>> On 2012-06-10 19:45, Ken Brown wrote:
>>> The bisection shows that the first problematic commit is this one:
>>>
>>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>>>
>>>
>>>
>>>
>>> Author: Ryan Lortie <desrt@desrt.ca>
>>> Date: Wed Aug 31 22:07:02 2011 -0400
>>>
>>> GMain: simplify logic for g_wakeup_acknowledge()
>>>
>>> Instead of messing around with context->poll_waiting, just look at the
>>> GPollFD to see if the GWakeup needs to be acknowledged.
>>>
>>> In case anyone else wants to confirm this, you can get my glib builds by
>>> running
>>>
>>> setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg
>>>
>>> and adding http://sanibeltranquility.com/cygwin to the list of mirrors.
>>> The problematic version is
>>>
>>> libglib2.0_0-2.30.90_7eae4861-1
>>>
>>> and the preceding version (without the problem) is
>>>
>>> libglib2.0_0-2.30.90_87880df-1
>>>
>>> I've tested the latter with emacs-23, emacs-24, and gvim.
>>
>> Thanks for doing this. Is this still only a problem with XP? If so, it
>> is most likely a bug in Cygwin itself.
>
> It's a problem with XP but not with Windows 7. No one has reported
> testing other systems.
>
> Do you understand the code well enough to make a test case to help cgf
> and Corinna debug it, assuming it's a Cygwin bug?

BTW, there's no easy way to revert the problematic commit, in view of 
this commit, which came on the next day:

http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=1c8c408c51c85230356cc95c06f2e1bd3f376624

The commentary that goes with that commit gives some explanations of 
what's supposed to happen.  It doesn't mean much to me, because of my 
ignorance of how glib works.  But maybe it will give you an idea where 
to look.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[K Stahl]

I've reverted the suggested libraries and still no success with GVim.
Keep getting either a failed execution (exit code 127) or bad address
for /usr/bin/gvim.

>
>
> On 6/11/2012 9:55 AM, K Stahl wrote:
>>
>> I've tried to revert the version of GLib 2.0 using the instructions
>> provided, but when I attempt to start GVim nothing happens.  The
>> process appears to fail without an explanation.  System WinXP and all
>> Cygwin libs updated to the latest.
>
>
> Did you also downgrade to
>
>  libgtk2.0_0-2.24.10-1
>  libgdk_pixbuf2.0_0-2.24.1-1
>  libpango1.0_0-1.29.4-2
>
> as explained in http://cygwin.com/ml/cygwin/2012-06/msg00043.html? There are
> two possible ways to do that:
>
> 1. If you still have those packages in your download directory, you can run
> setup.exe and choose "Install from Local Directory".
>
> 2. Otherwise, you can get them from the Cygwin Time Machine by running
> 'setup.exe -X' and adding
> ftp://www.fruitbat.org/pub/cygwin/circa/2012/05/08/111042 to the list of
> mirrors.
>
>
> Ken
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

Once again, please don't http://cygwin.com/acronyms/#TOFU .

On 6/11/2012 12:14 PM, K Stahl wrote:
> I've reverted the suggested libraries and still no success with GVim.
> Keep getting either a failed execution (exit code 127) or bad address
> for /usr/bin/gvim.

Try running rebaseall.  If that doesn't help, check your installed GNOME 
components to see if there's anything else that should be downgraded. 
It probably wouldn't hurt to just downgrade all of them.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[K Stahl]

rebaseall appears to resolved the issue.  GVim is running as expected!

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/11/2012 11:10 AM, Ken Brown wrote:
> On 6/11/2012 7:39 AM, Ken Brown wrote:
>> On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
>>> On 2012-06-10 19:45, Ken Brown wrote:
>>>> The bisection shows that the first problematic commit is this one:
>>>>
>>>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Author: Ryan Lortie <desrt@desrt.ca>
>>>> Date: Wed Aug 31 22:07:02 2011 -0400
>>>>
>>>> GMain: simplify logic for g_wakeup_acknowledge()
>>>>
>>>> Instead of messing around with context->poll_waiting, just look at the
>>>> GPollFD to see if the GWakeup needs to be acknowledged.
>>>>
>>>> In case anyone else wants to confirm this, you can get my glib
>>>> builds by
>>>> running
>>>>
>>>> setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg
>>>>
>>>> and adding http://sanibeltranquility.com/cygwin to the list of mirrors.
>>>> The problematic version is
>>>>
>>>> libglib2.0_0-2.30.90_7eae4861-1
>>>>
>>>> and the preceding version (without the problem) is
>>>>
>>>> libglib2.0_0-2.30.90_87880df-1
>>>>
>>>> I've tested the latter with emacs-23, emacs-24, and gvim.
>>>
>>> Thanks for doing this. Is this still only a problem with XP? If so, it
>>> is most likely a bug in Cygwin itself.
>>
>> It's a problem with XP but not with Windows 7. No one has reported
>> testing other systems.
>>
>> Do you understand the code well enough to make a test case to help cgf
>> and Corinna debug it, assuming it's a Cygwin bug?
>
> BTW, there's no easy way to revert the problematic commit, in view of
> this commit, which came on the next day:
>
> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=1c8c408c51c85230356cc95c06f2e1bd3f376624
>
>
> The commentary that goes with that commit gives some explanations of
> what's supposed to happen. It doesn't mean much to me, because of my
> ignorance of how glib works. But maybe it will give you an idea where to
> look.

One further data point: I tried the 2012-01-11 cygwin snapshot, and the 
problem is still there.  So if it's a Cygwin bug, it isn't one that was 
introduced in the last 5 months.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/10/2012 8:45 PM, Ken Brown wrote:
> The bisection shows that the first problematic commit is this one:
>
> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>
>
> Author: Ryan Lortie <desrt@desrt.ca>
> Date: Wed Aug 31 22:07:02 2011 -0400
>
> GMain: simplify logic for g_wakeup_acknowledge()
>
> Instead of messing around with context->poll_waiting, just look at the
> GPollFD to see if the GWakeup needs to be acknowledged.

I think this commit contains a typo: "events" should be "revents". 
(context->wake_up_rec.events is always nonzero at this point in the 
code, so it makes no sense to test that.)  As a result, 
g_wakeup_acknowledge() is being called much more often than necessary. 
I think this could easily explain the performance problems that have 
been reported, but I won't have a chance to test this on my (slow) XP 
system for a while, and possibly not until tomorrow.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/13/2012 2:40 PM, Ken Brown wrote:
> On 6/10/2012 8:45 PM, Ken Brown wrote:
>> The bisection shows that the first problematic commit is this one:
>>
>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>>
>>
>>
>> Author: Ryan Lortie <desrt@desrt.ca>
>> Date: Wed Aug 31 22:07:02 2011 -0400
>>
>> GMain: simplify logic for g_wakeup_acknowledge()
>>
>> Instead of messing around with context->poll_waiting, just look at the
>> GPollFD to see if the GWakeup needs to be acknowledged.
>
> I think this commit contains a typo: "events" should be "revents".
> (context->wake_up_rec.events is always nonzero at this point in the
> code, so it makes no sense to test that.) As a result,
> g_wakeup_acknowledge() is being called much more often than necessary. I
> think this could easily explain the performance problems that have been
> reported, but I won't have a chance to test this on my (slow) XP system
> for a while, and possibly not until tomorrow.

I've confirmed that fixing the typo solves the problem on my XP system. 
  I suspect that this issue is not specific to XP after all and has more 
to do with the slowness of the machine, so that the performance problem 
is more noticeable.  In any case, it's clearly a glib bug.

I've filed a bug report upstream:

   https://bugzilla.gnome.org/show_bug.cgi?id=678052

Ken




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Christopher Faylor]

On Wed, Jun 13, 2012 at 05:07:17PM -0400, Ken Brown wrote:
>On 6/13/2012 2:40 PM, Ken Brown wrote:
>> On 6/10/2012 8:45 PM, Ken Brown wrote:
>>> The bisection shows that the first problematic commit is this one:
>>>
>>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>>>
>>>
>>>
>>> Author: Ryan Lortie <desrt@desrt.ca>
>>> Date: Wed Aug 31 22:07:02 2011 -0400
>>>
>>> GMain: simplify logic for g_wakeup_acknowledge()
>>>
>>> Instead of messing around with context->poll_waiting, just look at the
>>> GPollFD to see if the GWakeup needs to be acknowledged.
>>
>> I think this commit contains a typo: "events" should be "revents".
>> (context->wake_up_rec.events is always nonzero at this point in the
>> code, so it makes no sense to test that.) As a result,
>> g_wakeup_acknowledge() is being called much more often than necessary. I
>> think this could easily explain the performance problems that have been
>> reported, but I won't have a chance to test this on my (slow) XP system
>> for a while, and possibly not until tomorrow.
>
>I've confirmed that fixing the typo solves the problem on my XP system. 
>  I suspect that this issue is not specific to XP after all and has more 
>to do with the slowness of the machine, so that the performance problem 
>is more noticeable.  In any case, it's clearly a glib bug.
>
>I've filed a bug report upstream:
>
>   https://bugzilla.gnome.org/show_bug.cgi?id=678052

What incredible perseverence you've shown in tracking this down.  Bravo!

cgf

P.S. I'm relieved and amazed that this didn't boil down to a Cygwin
bug.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[K Stahl]

Thank you Ken for first providing a useable patch and then finding the problem!

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ryan Johnson]

On 13/06/2012 5:40 PM, Christopher Faylor wrote:
> On Wed, Jun 13, 2012 at 05:07:17PM -0400, Ken Brown wrote:
>> On 6/13/2012 2:40 PM, Ken Brown wrote:
>>> On 6/10/2012 8:45 PM, Ken Brown wrote:
>>>> The bisection shows that the first problematic commit is this one:
>>>>
>>>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>>>>
>>>>
>>>>
>>>> Author: Ryan Lortie<desrt@desrt.ca>
>>>> Date: Wed Aug 31 22:07:02 2011 -0400
>>>>
>>>> GMain: simplify logic for g_wakeup_acknowledge()
>>>>
>>>> Instead of messing around with context->poll_waiting, just look at the
>>>> GPollFD to see if the GWakeup needs to be acknowledged.
>>> I think this commit contains a typo: "events" should be "revents".
>>> (context->wake_up_rec.events is always nonzero at this point in the
>>> code, so it makes no sense to test that.) As a result,
>>> g_wakeup_acknowledge() is being called much more often than necessary. I
>>> think this could easily explain the performance problems that have been
>>> reported, but I won't have a chance to test this on my (slow) XP system
>>> for a while, and possibly not until tomorrow.
>> I've confirmed that fixing the typo solves the problem on my XP system.
>>   I suspect that this issue is not specific to XP after all and has more
>> to do with the slowness of the machine, so that the performance problem
>> is more noticeable.  In any case, it's clearly a glib bug.
>>
>> I've filed a bug report upstream:
>>
>>    https://bugzilla.gnome.org/show_bug.cgi?id=678052
> What incredible perseverence you've shown in tracking this down.  Bravo!
++

Amazing. This is one of the nastier kinds of bugs I've seen anybody 
track down... bug not where anybody thinks it is, and in library code 
generally assumed to be robust, bisecting the monster that is glibc, bug 
hunter knows (or willing to learn) glibc well enough to tell what 
revents and events do (and that revents even exists!), but not so well 
that the eyes glossed over the typo.

Ironically, the 'r' key on my laptop has been acting up lately, so I can 
totally relate to the poor fellow who tried to type 'revents' and didn't 
notice when 'events' compiled and checked in instead...

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Performance problems with emacs-X11 in current cygwin

[Ken Brown]

On 6/14/2012 3:18 PM, Ryan Johnson wrote:
> On 13/06/2012 5:40 PM, Christopher Faylor wrote:
>> On Wed, Jun 13, 2012 at 05:07:17PM -0400, Ken Brown wrote:
>>> On 6/13/2012 2:40 PM, Ken Brown wrote:
>>>> On 6/10/2012 8:45 PM, Ken Brown wrote:
>>>>> The bisection shows that the first problematic commit is this one:
>>>>>
>>>>> http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Author: Ryan Lortie<desrt@desrt.ca>
>>>>> Date: Wed Aug 31 22:07:02 2011 -0400
>>>>>
>>>>> GMain: simplify logic for g_wakeup_acknowledge()
>>>>>
>>>>> Instead of messing around with context->poll_waiting, just look at the
>>>>> GPollFD to see if the GWakeup needs to be acknowledged.
>>>> I think this commit contains a typo: "events" should be "revents".
>>>> (context->wake_up_rec.events is always nonzero at this point in the
>>>> code, so it makes no sense to test that.) As a result,
>>>> g_wakeup_acknowledge() is being called much more often than
>>>> necessary. I
>>>> think this could easily explain the performance problems that have been
>>>> reported, but I won't have a chance to test this on my (slow) XP system
>>>> for a while, and possibly not until tomorrow.
>>> I've confirmed that fixing the typo solves the problem on my XP system.
>>> I suspect that this issue is not specific to XP after all and has more
>>> to do with the slowness of the machine, so that the performance problem
>>> is more noticeable. In any case, it's clearly a glib bug.
>>>
>>> I've filed a bug report upstream:
>>>
>>> https://bugzilla.gnome.org/show_bug.cgi?id=678052
>> What incredible perseverence you've shown in tracking this down. Bravo!
> ++
>
> Amazing. This is one of the nastier kinds of bugs I've seen anybody
> track down...

Thanks.  I actually enjoyed learning some new things, though it was 
frustrating at times.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple