GeezerVison

I have no real opinion on whether this is better or worse but for background, the reason I chose 4 is that:

1. I guesstimated that the average machine has 8 cores, and
2. libuv's thread pool is also 4 threads big by default.

(4 + 4 technically actually overcommits because of the main thread but a little overcommit seems like a decent trade-off vs. under-utilization.)

One glorious day we'll be able to service libuv and V8 from a single thread pool but until then, we need to strike a balance that doesn't starve one or the other.

Aside, the way to benchmark this is to:

1. Have a lot of functions that get promoted to the optimized tier around the same time, and
2. Execute a decent number of (asynchronous) file-based operations, like writing numerous small chunks to a bunch of on-disk files.

Those combined will overload both thread pools to the point that they need to queue up work items and then it's a matter of measuring throughput and latency.

Aside aside, as a stop-gap measure we could tweak node to divide the cores between the two thread pools at start-up.

How aggressive is V8 at consuming the available cores when the default is set to 0? I definitely think that we should look at benchmarking this more before making changes here.

How aggressive is V8 at consuming the available cores when the default is set to 0?

It varies. V8 allocates up to three threads for concurrent sweeping; any remaining threads are used for concurrent recompilation and on-stack replacement. It depends on the performance profile of the application whether those threads have work to do.

Would it be possible / desirable to run benchmarks across machines with variable numbers of cores and use that to determine a more algorithmic way of determining the reasonable defaults?

Here's one idea: rather than guessing at this, perhaps add a CLI flag to allow the default to be overridden? e.g. node --v8-default-thread-pool-size=0. The flag would likely not be used extensively so we could just add it to the man page but omit it from the node --help output. Having it would allow someone to go through and experiment with benchmarks using different values to figure out what is optimum.

Here's one idea: rather than guessing at this, perhaps add a CLI flag to allow the default to be overridden? e.g. node --v8-default-thread-pool-size=0. The flag would likely not be used extensively so we could just add it to the man page but omit it from the node --help output. Having it would allow someone to go through and experiment with benchmarks using different values to figure out what is optimum.

Sounds like a good idea, however I don’t like having undocumented features. Another approach could be to have an --advanced-options flag, much like we currently have for --v8-options and include --v8-default-thread-pool-size=0 under that?

That's certainly a possibility but not sure it's ideal until we have more than one flag that would fall under that kind of category. Adding it to the --help output would be fine.

Here's one idea: rather than guessing at this, perhaps add a CLI flag to allow the default to be overridden? e.g. node --v8-default-thread-pool-size=0. The flag would likely not be used extensively so we could just add it to the man page but omit it from the node --help output. Having it would allow someone to go through and experiment with benchmarks using different values to figure out what is optimum.

Ok, I am working on this at the moment.

Is this PR still being worked on?

ping @tangxinfa

It's been subsumed by PR #4344. I'll close this one.