bug-xboard
[Top][All Lists]
Advanced

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

Re: [Bug-XBoard] Re: Extremely slow startup


From: h.g. muller
Subject: Re: [Bug-XBoard] Re: Extremely slow startup
Date: Thu, 05 Aug 2010 09:50:08 +0200

At 12:23 4-8-2010 -0400, Adrian Petrescu wrote:
I couldn't resist so I kept investigating. It seems the problem is not specific to XSync -- I tried removing all calls to XSync and XSynchronize in xboard.c. The problem magically moved over to the XSetArg calls in ModeHighlight(). I commented those calls out, and the problem magically moved to the XGetWindowAttributes() call in CreateAnimVars().

So my conclusion is that my system is just taking a very long time to execute whatever happens to be the first call to xlib during a particular execution.

Many thanks for your thorough tracing of the problem.
I don't think it is the first call to xlib. The XSync you pinpointed is in the routine to drw the board, and this is only called after there has already been a lot of setting up of window sies and menus through X. I don't know much about X either, but I get the feeling that X-calls are asynchronous (hence the need for an XSync), so that they would normally return instantaneously, no matter how long it takes to perform them. (Unless they have to satisfy a data request, of course.) So what might happen is that some early X-call stalls, and all those after it are queued, untill the queue fills up. In that case the call where we detect the delay might not be the call that causes it at all. This will make it very hard to identify the problem by direct attack.

We do have one more ace on our sleeves, though: It seems you don't have the same problem in XBoard 4.4.2. Now the development version should not be that much different from 4.4.2 in this part. There was a lot of code moved around between 4.2.7 and 4.4.0 in xboard.c. But between 4.4.0 and the development version, the main front-end changes that come to mind that would be active during startup are the automatic opening
of the auxiliary windows (when the settings file requests this).

One way to narrow it down is to try different versions from the git history, to establish where the problem first occurs. Did the last common ancestor of 4.4.2 and the master branch already have this problem? If not, we can establish by bisection at which commit in the master branch this problem first occurs. That should show us what new things
were requested from X that introduced the problem.

We should be alert that this can also have something to do with changes in the make file, in particular the linker flags. Several illusive problems in the past could be linked to the order in which the libraries were mentioned.




reply via email to

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