Re: [Bug-XBoard] Re: Extremely slow startup
At 22:33 3-8-2010 -0400, Adrian Petrescu wrote: Here is a strange symptom that may illuminate the issue or make it more puzzling. You decide which. This will indeed be a tough cookie... For me, startup of XBoard under Ubuntu is fast, so I cannot test it myself. It sounds like XBoard is making a system request that your system has big trouble in satisfying. What are you seeing durng these 10 seconds? Is the XBoard main window already up, and is the Chess board properly displayed? Are any of the auxiliary windows already up? The most passive mode to bring XBoard up in is -ncp (with -ics you might still hang because of connection problems with the ICS), so perhaps you should always test on that. Could you start XBoard with the -debug option? This should make a file xboard.debug, and if we are lucky, we can establish from that where it hangs. I think it does print some progress reports during the startup process, from main() in xboard.c. If not, we should add some fprintf(stderr, "..."); there to figure out where it hangs. There are no time stamps with debug messages from XBoard itself, though. So to see where it hangs, it might be necessary to kill it during those 10 sec. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org http://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Re: Extremely slow startup
Hello :)
Thanks for the response. I did a bunch of testing and I've pinpointed the
problem: it seems the call to XSync is extremely slow. On line 4568 of
xboard.c if I do:
printf("About to call XSync\n");
XSync(xDisplay, False);
printf("Done calling XSync\n");
Then the "About to call XSync" gets printed right before the long, painful
hang, and "Done calling XSync" gets called right when it recovers. The two
prints are about 10 seconds apart. So I think this is definitely the issue.
Unfortunately I'm not very familiar with low-level X programming to be able
to diagnose this right away -- it's way before my time :) I'll take more of
a look if nobody here knows what might be the cause off the top of their
heads.
Cheers,
Adrian
On Wed, Aug 4, 2010 at 5:53 AM, h.g. muller wrote:
> At 22:33 3-8-2010 -0400, Adrian Petrescu wrote:
>
>> Here is a strange symptom that may illuminate the issue or make it more
>> puzzling. You decide which.
>>
>
> This will indeed be a tough cookie...
>
> For me, startup of XBoard under Ubuntu is fast, so I cannot test it myself.
>
> It sounds like XBoard is making a system request that your system has big
> trouble in satisfying.
> What are you seeing durng these 10 seconds? Is the XBoard main window
> already up, and
> is the Chess board properly displayed? Are any of the auxiliary windows
> already up?
> The most passive mode to bring XBoard up in is -ncp (with -ics you might
> still hang because
> of connection problems with the ICS), so perhaps you should always test on
> that.
>
> Could you start XBoard with the -debug option? This should make a file
> xboard.debug,
> and if we are lucky, we can establish from that where it hangs. I think it
> does print some
> progress reports during the startup process, from main() in xboard.c. If
> not, we should
> add some fprintf(stderr, "..."); there to figure out where it hangs. There
> are no time stamps
> with debug messages from XBoard itself, though. So to see where it hangs,
> it might be
> necessary to kill it during those 10 sec.
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Re: Extremely slow startup
By the way, sorry for the double-post, but I really should mention, only the
first two calls to XSync during the lifetime of XBoard (once right after it
draws the board, and once right after it draws the menus at the top for the
very first time) are slow. All subsequent calls are perfectly normal and the
two prints come out instantly one after the other.
Cheers,
Adrian
On Wed, Aug 4, 2010 at 11:52 AM, Adrian Petrescu wrote:
> Hello :)
>
> Thanks for the response. I did a bunch of testing and I've pinpointed the
> problem: it seems the call to XSync is extremely slow. On line 4568 of
> xboard.c if I do:
>
> printf("About to call XSync\n");
> XSync(xDisplay, False);
> printf("Done calling XSync\n");
>
> Then the "About to call XSync" gets printed right before the long, painful
> hang, and "Done calling XSync" gets called right when it recovers. The two
> prints are about 10 seconds apart. So I think this is definitely the issue.
>
> Unfortunately I'm not very familiar with low-level X programming to be able
> to diagnose this right away -- it's way before my time :) I'll take more of
> a look if nobody here knows what might be the cause off the top of their
> heads.
>
> Cheers,
> Adrian
>
> On Wed, Aug 4, 2010 at 5:53 AM, h.g. muller wrote:
>
>> At 22:33 3-8-2010 -0400, Adrian Petrescu wrote:
>>
>>> Here is a strange symptom that may illuminate the issue or make it more
>>> puzzling. You decide which.
>>>
>>
>> This will indeed be a tough cookie...
>>
>> For me, startup of XBoard under Ubuntu is fast, so I cannot test it
>> myself.
>>
>> It sounds like XBoard is making a system request that your system has big
>> trouble in satisfying.
>> What are you seeing durng these 10 seconds? Is the XBoard main window
>> already up, and
>> is the Chess board properly displayed? Are any of the auxiliary windows
>> already up?
>> The most passive mode to bring XBoard up in is -ncp (with -ics you might
>> still hang because
>> of connection problems with the ICS), so perhaps you should always test on
>> that.
>>
>> Could you start XBoard with the -debug option? This should make a file
>> xboard.debug,
>> and if we are lucky, we can establish from that where it hangs. I think it
>> does print some
>> progress reports during the startup process, from main() in xboard.c. If
>> not, we should
>> add some fprintf(stderr, "..."); there to figure out where it hangs. There
>> are no time stamps
>> with debug messages from XBoard itself, though. So to see where it hangs,
>> it might be
>> necessary to kill it during those 10 sec.
>>
>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Re: Extremely slow startup
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. I imagine it'll be very hard for xboard developers to magically
intuit what part of my system is causing that particular problem -- it
doesn't seem to be xboard-specific although no other program on my machine
has this issue -- so I'll stop bugging this list about it unless somebody
has a brilliant flash of insight :) Which would be very much appreciated.
Thanks guys!
-Adrian
On Wed, Aug 4, 2010 at 11:54 AM, Adrian Petrescu wrote:
> By the way, sorry for the double-post, but I really should mention, only
> the first two calls to XSync during the lifetime of XBoard (once right after
> it draws the board, and once right after it draws the menus at the top for
> the very first time) are slow. All subsequent calls are perfectly normal and
> the two prints come out instantly one after the other.
>
> Cheers,
> Adrian
>
>
> On Wed, Aug 4, 2010 at 11:52 AM, Adrian Petrescu wrote:
>
>> Hello :)
>>
>> Thanks for the response. I did a bunch of testing and I've pinpointed the
>> problem: it seems the call to XSync is extremely slow. On line 4568 of
>> xboard.c if I do:
>>
>> printf("About to call XSync\n");
>> XSync(xDisplay, False);
>> printf("Done calling XSync\n");
>>
>> Then the "About to call XSync" gets printed right before the long, painful
>> hang, and "Done calling XSync" gets called right when it recovers. The two
>> prints are about 10 seconds apart. So I think this is definitely the issue.
>>
>> Unfortunately I'm not very familiar with low-level X programming to be
>> able to diagnose this right away -- it's way before my time :) I'll take
>> more of a look if nobody here knows what might be the cause off the top of
>> their heads.
>>
>> Cheers,
>> Adrian
>>
>> On Wed, Aug 4, 2010 at 5:53 AM, h.g. muller wrote:
>>
>>> At 22:33 3-8-2010 -0400, Adrian Petrescu wrote:
>>>
Here is a strange symptom that may illuminate the issue or make it more
puzzling. You decide which.
>>>
>>> This will indeed be a tough cookie...
>>>
>>> For me, startup of XBoard under Ubuntu is fast, so I cannot test it
>>> myself.
>>>
>>> It sounds like XBoard is making a system request that your system has big
>>> trouble in satisfying.
>>> What are you seeing durng these 10 seconds? Is the XBoard main window
>>> already up, and
>>> is the Chess board properly displayed? Are any of the auxiliary windows
>>> already up?
>>> The most passive mode to bring XBoard up in is -ncp (with -ics you might
>>> still hang because
>>> of connection problems with the ICS), so perhaps you should always test
>>> on that.
>>>
>>> Could you start XBoard with the -debug option? This should make a file
>>> xboard.debug,
>>> and if we are lucky, we can establish from that where it hangs. I think
>>> it does print some
>>> progress reports during the startup process, from main() in xboard.c. If
>>> not, we should
>>> add some fprintf(stderr, "..."); there to figure out where it hangs.
>>> There are no time stamps
>>> with debug messages from XBoard itself, though. So to see where it hangs,
>>> it might be
>>> necessary to kill it during those 10 sec.
>>>
>>
>>
>
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Re: Extremely slow startup
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. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org http://lists.gnu.org/mailman/listinfo/bug-xboard
