Why are systems timings using `cpuTime`?

[ul]

Hi, thanks for a wonderful ECS library, it was a pleasure to use so far!

I recently was surprised by the behaviour of my first system with timings: stRunEvery, as it was triggering much less frequently than I expected. Turned out, since I run systems on every frame, and they finish quickly, with the CPU utilisation way below 100%, cpuTime was ticking slower than the real time; c.f. cpuTime docs:

Gets time spent that the CPU spent to run the current process in seconds. This may be more useful for benchmarking than epochTime. However, it may measure the real time instead (depending on the OS). The value of the result has no meaning. To generate useful timing values, take the difference between the results of two cpuTime calls.

Is it a deliberate design choice?

[rlipsc]

Thanks for this. It's not a design choice, I didn't really consider what cpuTime was doing here in context. I suppose I've just been used to using cpuTime for benching and wanted the higher granularity, but it doesn't make sense to use it for stRunEvery.

Sounds like it's worth switching the timing over to epochTime!