Re: Bizarre x86 segment layout problem causing select() slowdown
Re: Bizarre x86 segment layout problem causing select() slowdown
- Subject: Re: Bizarre x86 segment layout problem causing select() slowdown
- From: John Daniel <email@hidden>
- Date: Mon, 5 Feb 2007 20:57:32 -0600
Dave,
I think your text segment issues are just a blessing in disguise.
Your factor of 50 slowdown is being caused by something else. You are
lucky because you can get the problem to manifest at will. That is
unusual for these problems. While you are in this state, you should
fix this bug before looking at anything else. If the problem
"mysteriously" goes away, that just means you are prime candidate for
the mystery slowdown to kick in after it is delivered due to some
random OS security patch or something. The final version of 10.5 may
very well cause your slowdown again.
Your two shark files are significantly different. I don't know enough
about Shark to really be able to decipher it though. I can tell that
the "good" run has one additional thread than the "bad" run. That
tells me you are comparing Apples to Oranges on these two runs. I
don't know if the amount of time in the select() calls is even
significant. You should stick to looking at your transfer rate. That
seems much more meaningful and easier to analyze. A good program
should spend 99% of its time blocked on select().
I think that changing the size of segments, adding no-ops, and adding
an empty function is changing the behavior of your problem. It is
changing the point at which a context switch occurs. Do you have a
clear handle on which specific parts of code can be run by multiple
threads? Remember, a dual-core x86 processor is going to have
radically different behavior than a PPC in these spots. I think that
is where you need to look.
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden