I've noticed during profiling that a huge amount of time is spent in the locks in xpcom/io/nsPipe2.cpp. In theory, I think we could eliminate entering and exiting locks when we can notice that the read cursor is in a different segment from the write cursor. Although tricky, this could give us a huge win. Since I wrote it, I'll look into it.

Fixing bug 26419 "PR_Lock() is slow on NT" or bug 20357 "JS thin locks fatter than fat locks?" (although that may an NT-only solution) could also potentially solve this problem.

Warren: how much benefit are we going to get from this? Also -- what's the likeliness that you'll get to it before beta?

still waiting for input...

Not feasible for beta1 -- what was I thinking?

Moving non-essential, non-beta2 and performance-related bugs to M17.

post-beta2

Warren, I am reassigning some bugs which you own over to me (dougt). If you think that you will have time to address them please reassign them back to yourself. This reassignment was suggested by choffman.

over to darin. He has recently played in this area.

Pushing milestone back to 0.9.1

with the somewhat recent change waterson made to stop holding the pipe lock while calling out to the ns{Write,Read}SegmentFun in {Read,Write}Segments, i think we solved 80% of this bug. so, i'm going to move this out to Future as we have much bigger fish to fry.

WONTFIX .. i'm not convinced the gain would be worth the pain at this point.