Hi Duy, On Tue, 3 Apr 2018, Duy Nguyen wrote:
> On Tue, Apr 3, 2018 at 11:31 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > It is very frustrating to spend that much time with only little gains > > here and there (and BusyBox-w32 is simply not robust enough yet, apart > > from also not showing a significant improvement in performance). > > You still use busybox-w32? Yes. > It's amazing that people still use it after the linux subsystem comes. I use WSL myself. But you need to realize that WSL is only available on Windows 10 (many users still use Windows 7), and it is a little tricky to get to work in Docker containers, I heard, so I did not even try. Also, many Windows users are unfamiliar with Linux, and forcing them to learn and install a Linux distribution on their machine when all they want is to use Git is a bit... much. > busybox has a lot of commands built in (i.e. no new processes) and > unless rmyorston did something more, the "fork" in ash shell should be > as cheap as it could be: it simply serializes data and sends to the new > process. Yes, I had the pleasure of reading that code. It might surprise you, but I had to come up with quite a bit of patches to make the test suite pass. And it does not really pass, as I randomly get hangs... > If performance does not improve, I guess the process creation cost > dominates. There's not much we could do except moving away from the > zillion processes test framework: either something C-based or another > scripting language (ok I don't want to bring this up again) There is no need to guess. I now have .pdb files, and once I have a good example of a shell script construct that is particularly slow, and once I find some time to work on it, I will dig into the bottlenecks. Ciao, Dscho
