This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks
that can be run on threads (and then waited for). It satisfies the following use cases:
* HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads.
* Thread spawning is slow in general, so reusing threads is faster anyway.
* This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks.
After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
This PR is a continuation of #50381 (which was implemented exactly a year ago!)
* Add a visual interface to select which classes should not be built into Godot (well, they are built if something else uses them, but if not used the optimizer will remove them out).
* Add a detection system to scan the project and figure out the actual classes used.
* Added the ability for SCons to load build profiles.
Obligatory Screen:
A simple test with a couple of nodes in the scene resulted in a 25% reduction for the final binary size
TODO:
* Script languages need to implement used class detection (left for another PR).
* Options to disable servers or server functionalities (like 2D or 3D physics, navigation, etc). Are missing, that should also greatly aid in reducing binary size.
* Options to disable some modules would be desired.
* More options to disable drivers (OpenGL, Vulkan, etc) would be desired.
In general this PR is a starting point for more contributors to improve and enhance this functionality.
The new option is `linker` and lets the user specify the argument to
the`-fuse_ld=` linker flag directly. The supported options are:
- `default`: No change, typically uses GNU ld (bfd) unless the user or
distro picked a different default `/usr/bin/ld`.
- `bfd`: GNU ld from binutils
- `gold`: GNU gold from binutils
- `lld`: lld from LLVM
- `mold`: mold, an extremely fast modern linker, not (yet) intended for
use in production but great for development speed. Provided by distro
`mold` package or needs to be compiled from source and installed to
`/usr` otherwise.
Removes the `use_lld=yes` option, and make lld actually usable with GCC
too.
Not all the above are compatible or recommend for LTO, we recommend
using GNU ld with GCC LTO, or lld with LLVM ThinLTO.
Read/write ops for this implementation are done through the java layer via jni, and so for good performance, it's key to avoid numerous repeated small read/write ops due the jni overhead.
The alternative is to allocate a (conversatively-sized) large buffer to reduce the number of read/write ops over the jni boundary.
