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: Eric Albert <email@hidden>
- Date: Fri, 2 Feb 2007 21:21:39 -0800
On Feb 2, 2007, at 5:46 PM, Dave Hayden wrote:
This is definitely one of the weirdest problems I've run into so
far. We discovered that network performance in the latest release
of our Usenet app Unison was severely degraded on intel machines--
instead of getting the usual ~400K/s transfer rate, it was pulling
1-10% of that. Shark said it's spending all its time in select(). I
didn't see the same problem in debug builds either, so, figuring it
might be an optimizer bug, I made a small tweak that actually
"fixed" the bug. But I couldn't spot the problem in the generated
code, so I poked around more.
All I can make out is that something about the segment layout seems
to be the cause: if I add enough nop instructions to shift the
start of the __text section of the __TEXT segment, it goes away.
I've moved nops around so that the select() call is at the same
address but the segment size is bigger, and it also fixes it. If I
add a whole page of 4096 nops, it's slow again. I don't know enough
about the system guts to imagine how segment layout could have any
effect on the select() calls..
The "slow" build runs fast again in 10.5, so either the problem's
been found and fixed there, or the factors causing this have
shifted their requirements. I'd be a lot happier if I knew it's the
former and I won't have to worry that select() will choke up
because my code happens to be the wrong size.
Anyone have any ideas? Any more information I can provide, short of
the full source to the app? Is there a better place (another
mailing list? Radar?) to ask this question?
Apologies for saying this, but that fix doesn't make any sense. The
OS doesn't really care about the size of your code (which is what the
__TEXT,__text section is used for).
For that matter, select() is a blocking call. I wouldn't expect an
app to spend any measurable amount of time using the CPU there.
Instead, it'll sit there waiting for data to appear on the fds or for
the timeout to be hit. Are you using a very short timeout or
anything like that?
What led you to start adding nops in the first place? That's not a
common attempted fix for a performance problem. Perhaps a
description of whatever led you to go down that path will help folks
here figure out what you can look at to fix the problem in a more
typical way.
-Eric
_______________________________________________
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