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

[h.g. muller]

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.