Post by steadyeddie on Dec 18, 2016 6:18:57 GMT -8
The more I write, the more I realise the 1 control thread is clearly barmy in the long run (high CPU cores world). Oh well, it's what I've got for now.
Turn on a profiler against your Player for the first time and you'll find a bunch of crass performance bugs. Once I'd taken mine out, for a game where the control thread was the bottleneck (C4 is may favorite), I found the following:
⦁ If you are blocked in methods near a synchronize, it's the synchronize- find another way.
⦁ You need to be very careful with processing results and back propagation (see later).
⦁ Actually, posting and reading from the worker queues is not that expensive if you get the locking right.
⦁ Selection of nodes is surprisingly expensive. First up I discovered an inaccurate, but fast version of Math.log that has helped me a lot. And caching of values to avoid recalculation.
Turn on a profiler against your Player for the first time and you'll find a bunch of crass performance bugs. Once I'd taken mine out, for a game where the control thread was the bottleneck (C4 is may favorite), I found the following:
⦁ If you are blocked in methods near a synchronize, it's the synchronize- find another way.
⦁ You need to be very careful with processing results and back propagation (see later).
⦁ Actually, posting and reading from the worker queues is not that expensive if you get the locking right.
⦁ Selection of nodes is surprisingly expensive. First up I discovered an inaccurate, but fast version of Math.log that has helped me a lot. And caching of values to avoid recalculation.
