OptiTest is a runtime code performance optimizer, you supply it with variables in code blocks to test over certain ranges and it will automatically profile and select the best performers for you.The demo scene materials were created with URP, but the code itself is relevant to all rendering pipelines.It takes a lot of developer time to create performant code for games that will work well across different architectures and specs.OptiTest simplifies that process for you by automatically testing some given variables and selecting/using the best sampled values.As an example (there's a lot more information in the documentation):Imagine we are using threading to perform Unit updates. We want to use threading because in our case updating 100 units takes a few ms, so if that scales up to 1024 then our game is no longer functional.So we implement threading and are processing our units with general values, for example 16 threads and each thread is working with 64 units in a loop.With these generalized values it might perform ok, but what if instead of that we used 24 threads, or different loop sizes that ran better on the client PC? We could test extensively and select optimal (developer PC) values, but those might not be optimal on a client PC. Or our Unit struct size suddenly changes and now all of our tests are invalidated because less/more units fit into a given CPU L1 cache size.With OptiTest we simply supply it with a value (let's call it loopCount) and the range of values to test, such as 1-1024. LoopCount will be the range of the for loop in each thread, and we can calculate how many threads to launch from total / loopCount (+ remainder etc.)Human intuition often make us use values such as 64 or 256 for loopCount, but in the included Demo 3 we test and see how well that works. For us a loopCount of 543 outperforms 64 and 256 by 3.5x and 1.35x respectively and out of 1024 samples they only place in 940th and 572nd overall.Three algorithmsBinary Inner - Search in a binary fashion but using midLeft, mid, midRight so as to avoid poor edge samples (where left = min, right = max)Binary Outer - Still binary but using left, mid and right to perform a faster searchSweep - Binary might miss localized peaks, can use Sweep with a distance to fit more correctly; but will be slowerFirst two demos show the algorithms vs a few artificial timing workloads, whereas the 3rd demo uses their code to show a real sample. We create the graphs from the screenshots via Advanced MeshAPI, so why no let OptiTest figure out good values for doing it multithreaded with threadCount vs inner loopCountYou can use 1 to N tests in one OptiTest, intermixed with rest periodsThe search will automatically narrow and rest for longer inbetween testsBut you can either manually wake and reset it, or have it do so automatically via the change of some value, for example when you've added more than N% new units, then your cache sizes might change and the best samples might shiftRoadmap included in the documentation
