SDL_PumpEvents() seems to be the cause of the execution delay. If you don't call it often enough it appears to take longer to execute.
Yeah, this is what my tests show (see the next paragraph).
You can test this by putting a call to SDL_PumpEvents() ahead of the time measurement code:
This is exactly what I did yesterday and the results are clear — the following measurements of the uptime of
SDL_PumpEvents itself:
time: 0.193ms | sample: 1934 | events: 26 // too long
time: 0.008ms | sample: 82 | events: 31
time: 0.039ms | sample: 392 | events: 31
time: 0.008ms | sample: 79 | events: 31
time: 0.206ms | sample: 2062 | events: 32 // too long
time: 0.008ms | sample: 79 | events: 31
time: 0.039ms | sample: 390 | events: 31
time: 0.178ms | sample: 1777 | events: 31 // too long
time: 0.232ms | sample: 2316 | events: 32 // too long
time: 0.055ms | sample: 546 | events: 25
time: 0.039ms | sample: 391 | events: 30
time: 0.008ms | sample: 82 | events: 30
time: 0.952ms | sample: 9519 | events: 43 // too long
time: 1.323ms | sample: 13228 | events: 47 // too looooooooong!
time: 0.040ms | sample: 396 | events: 42
time: 0.008ms | sample: 82 | events: 44
time: 0.219ms | sample: 2190 | events: 51 // too long
time: 0.008ms | sample: 80 | events: 43
time: 0.039ms | sample: 391 | events: 48
time: 0.007ms | sample: 67 | events: 45
time: 0.097ms | sample: 968 | events: 43
time: 0.008ms | sample: 79 | events: 49
time: 1.818ms | sample: 18183 | events: 47 // too looooooooong!
time: 0.008ms | sample: 78 | events: 44
time: 0.045ms | sample: 445 | events: 18
time: 0.008ms | sample: 80 | events: 0
time: 0.045ms | sample: 449 | events: 0
time: 0.008ms | sample: 80 | events: 0
time: 0.045ms | sample: 447 | events: 0
time: 0.008ms | sample: 79 | events: 0
time: 0.045ms | sample: 445 | events: 0
time: 0.005ms | sample: 52 | events: 0
time: 0.008ms | sample: 81 | events: 0
time: 0.008ms | sample: 84 | events: 0
time: 0.040ms | sample: 402 | events: 9
time: 0.269ms | sample: 2687 | events: 32 // too long
time: 0.272ms | sample: 2717 | events: 13 // too long
time: 0.041ms | sample: 408 | events: 31
On the other hand, a single call to the
SDL_PeepEvents function, returning dozens of events, always takes about 0.001ms (i.e. 1µs). I tested it yesterday too.
I checked using the
Intel® VTune™ Profiler and unfortunately it looks like it is not SDL's fault, but the system's fault (see the attachment). It's just a pity that this profiler has some problems recognizing my CPU and that it shows the addresses of some functions instead of their names (SDL functions).
Any other lightweight and sensible Windows 10 64-bit profiling tool for native applications?This Intel tool not only weighs 2GB, it also does not show some data (such as function names).
LazProfiler would be great, I installed it, but Lazarus crashes during boot. I changed the code as
suggested in this pull request, but it doesn't help — when Lazarus starts, the IDE freezes for several seconds, and then an error pops up. Dammit...