On Thu, Apr 17, 2014 at 11:52:56PM +0200, Johannes Schindelin wrote: > > I tried running the test on my Linux box, but it doesn't fail with the > > existing recursive code. > > I cannot recall how I came to choose 64, but I *think* I only tested on > Windows, and I *think* I reduced the number of tags in order to make > things faster (Windows is *unbearably* slow with spawn-happy programs such > as Git's tests -- literally every single line in a shell script tests the > patience of this developer, running the complete test suite with 15 > parallel threads takes several hours, no kidding). Yeah, I figured speed had something to do with it. However, since you are using a bash loop to generate the input (and it should all be done as builtins in bash, I think), and fast-import to create the objects, I don't think bumping it will actually increase your process count. > > The results are strangely non-deterministic, but with -O0, we generally > > die reliably below about 60. With -O2, though, it's more like 43. We > > can't go _too_ low here, though, as lots of things start breaking around > > 32. > > How about using 40, then? I am more interested in reducing the runtime > than reducing the number of false negatives. The problem will be exercised > enough on Windows, but not if the test suite becomes even slower than it > already is. I'm OK with doing that. My biggest concern is that it will cause false positives on systems that are hungrier for stack space, but we can address that if it happens. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html