> Date: Thu, 30 Jan 2025 09:12:36 +0200
> From: Eli Zaretskii
> To: "Yue Yi"
> > In this implementation, when there are a large number of child processes
> > (around 1000), the maximum call time for accept-process-output does not
> > exceed 100 microseconds. However, there might still be room for
> > improvement.
>
> AFAIR, you said that starting new threads each time meant the timing
> was 160 microseconds (vs just 2 usec without threads)? If so, the
> improvement due to using thread pool is a bit disappointing, no? If
> the time cannot be reduced to, say, 25 usec (which is already 10 times
> the current performance), then maybe the additional complexities of
> using a thread pool are not justified, and we should live with the
> slower subprocess responses when there's more than 30 of them?
Without using a thread pool, there is a significant time jump when
transitioning from not needing a thread to needing one: from 2 usec to
160 usec, as I described earlier. In this case, if threads are created
only at the time of the call, the time would be an astonishing 4 ms when
we have about 1000 subprocesses.
After using the thread pool, the transition from not needing a thread to
needing one changes from 2 usec to 12 usec. I mean, after using a
thread pool, even when we have many subprocesses running simultaneously
(around 1000 subprocesses correspond to needing about 32 threads), call
time of `accept-process-output' does not exceed 100 microseconds.
Of course, the waiting time will increase as the number of threads
grows, even if we use a thread pool. I think I need to find a reasonable
upper limit to ensure that the call time does not exceed an acceptable
value.
> > By the way, can I use _WIN32_WINNT to check the current Windows version
> > and make the most of some system features, such as the thread pool? I
> > will compare the performance of the system thread pool with my own
> > implementation to decide whether to use them.
>
> [...]
>
> You will find many examples of using these techniques in w32*.c source
> files, and we can discuss what to do in specific situations you
> encounter as part of working on this feature.
Thanks, see you next month :)