this isn't released yet so it's OK to change.
phpstan level 7 doesn't like these kinds of ambiguous return types because there's no way for it to tell which type is returned without a return type specifying extension, and it's easier to just change the API than to make PHPStan understand it.
this isn't required by the spec and PHPStan chokes on it. I was previously having it ignore these errors, but it turns out that PHPStan is not making use of extended typeinfo provided if it can't parse the tag, which is problematic on level 6 and also a problem for array-of-type. Therefore, we are going to have to take the hit.
This is better for performance because these then don't need to be reevaluated every time they are called.
When encountering an unqualified function or constant reference, PHP will first try to locate a symbol in the current namespace by that name, and then fall back to the global namespace.
This short-circuits the check, which has substantial performance effects in some cases - in particular, ord(), chr() and strlen() show ~1500x faster calls when they are fully qualified.
However, this doesn't mean that PM is getting a massive amount faster. In real world terms, this translates to about 10-15% performance improvement.
But before anyone gets excited, you should know that the CodeOptimizer in the PreProcessor repo has been applying fully-qualified symbol optimizations to Jenkins builds for years, which is one of the reasons why Jenkins builds have better performance than home-built or source installations.
We're choosing to do this for the sake of future SafePHP integration and also to be able to get rid of the buggy CodeOptimizer, so that phar and source are more consistent.
This has the triple bonus effect of a) making a lot of code easier to read, b) reducing Server::getInstance() usages, and c) removing a whole bunch of Server dependencies.
The network and block namespaces are untouched by this commit due to potential for merge conflicts. These should be dealt with separately on master.
This changes how the AsyncPool works so that it does not immediately always start all of the workers in the pool.
Instead, workers will be started only when an idle worker was not found.
This allows for significant memory footprint reductions while idle.
In effect the async-workers setting in pocketmine.yml now dictates a _maximum_ pool size, not a fixed pool size.
This commit contains quite a few breaking changes with respect to how AsyncTasks are handled. This is necessary to allow separation of the ServerScheduler and the AsyncPool, because in the future the ServerScheduler may be removed and instead there will be isolated per-plugin sync-task schedulers - but we cannot have every plugin with its own worker pool for memory usage reasons if nothing else.
The following things have changed:
- ServerScheduler: scheduleAsyncTask(), scheduleAsyncTaskToWorker(), getAsyncTaskPoolSize(), increaseAsyncTaskPoolSize() and similar methods have all been removed. Additionally the static \$WORKERS field has been removed.
- Server: added API method getAsyncPool(). This grants you direct access to the server's AsyncPool. Calls to getScheduler()->scheduleAsyncTask() and scheduleAsyncTaskToWorker() should be replaced with getAsyncPool()->submitTask() and submitTaskToWorker() respectively.
Re-implement chunk sending, send chunks inside a radius instead of below a count
This sends chunks in concentric squares around players. When the radius is hit, it will pad out the radius until a full circle of chunks is loaded around the player.
TODO: implement radius-per-tick, send chunks in concentric circles, use radius for player spawning.
To set your server chunk radius, change `view-distance` in server.properties. Values are intended to be the same as MCPE render distance values. With matching client and server render distances the chunks should reach the horizon.
NOTE: You may notice significantly increased memory usage per player when increasing these values to something respectable. This is normal and expected.
A player with render distance 14 for example will cause loading of 600+ chunks. A player cannot however exceed the render distance limit set in server.properties - the server will simply not send any more chunks.
Render distance of 8 chunks is approximately 200 chunks. This is roughly equivalent to the original default max-chunks of 192 in pocketmine.yml, but sent in a circle instead of a square.
Wait for client to request a chunk radius before ordering chunks
Use 8 for default maximum radius (roughly matches old setting of 192)
Calculate spawn chunk count from chunk-sending.spawn-radius
