On Sat, 4 Apr 2009, Jeff King wrote: > On Sat, Apr 04, 2009 at 01:20:18PM -0500, Dan McGee wrote: > > > > That makes sense to me, though I wonder if it may confuse and frustrate > > > users who are expecting their awesome quad-core machine to be using 4 > > > threads when it only uses 2. Is it worth printing both values, or some > > > indicator that we could have been using more? > > > > I thought of this, but decided it wasn't really worth it. The default > > window size of 10 makes it a very rare case that you will use fewer > > than 4 threads. With the default, each thread needs a minimum of 20 > > objects, so even a 100-object repository would spawn the 4 threads. > > Good point. Though by that logic, isn't your patch also not worth it > (i.e., it is unlikely not to fill the threads, so the output will be the > same with or without it)? > > I still think yours is an improvement, though, however slight. I don't think this is worth it at all. This display is there mainly to confirm expected number of available threads. The number of actually active threads is an implementation detail. Sure if the number of objects is too low, or if the window size is too large, then the number of active threads will be lower. But in practice it is also possible that with some patological object set you end up with 2 threads out of 4 completing very quickly and the other 2 threads still busy with big objects and total remaining work set too small to split it further amongst idle threads, meaning that you'll end up with only 2 busy CPUs even though the display said 4 threads initially even with this patch. In other words I don't think this patch is a good idea as we don't update the display with remaining active threads along the way. Nicolas -- 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
