cycle 2. Stage 3, day 17:
I did stumble into another spectacular improvement. Many months ago, I took great care to eliminate every memory allocation out of the hot path.
The most insidious allocation is the one that you don't even suspect that it is there at all...
I attribute again this powerful discovery to luck.. Yes one more time, luck... I say that very often since I have started to use UMS.
Here is the chain of thoughts that made me discover this gem.
After dinner, I was reading one of my favorite news website and I have found an article announcing the new release of a memory allocator lib:
https://www.phoronix.com/scan.php?page=n...3-Released
This made me think that I have never really did run a heap profiler on my software. I did attempt to run valgrind on it but for some reason, my app is corrupting valgrind and nothing good can come out of a valgrind run. I suspect that it might be because my app is launching kernel threads through io_uring and valgrind does not like that at all...
Anyway, I did search the net to see if I could find another good heap profiler that will run nicely with my app. I did find heaptrack:
https://github.com/KDE/heaptrack
and it works very well...
This made me discover that my #1 memory allocation spot was inside std:: stable_sort(). I even had no idea that this function was allocating memory. This function is called something like 4 million times every 5 minutes or so. I have replaced calls to stable_sort to something else not allocating. I am currently testing this new improvement... Not sure yet by how much it will improve my reaction time but it should make a difference...
I did stumble into another spectacular improvement. Many months ago, I took great care to eliminate every memory allocation out of the hot path.
The most insidious allocation is the one that you don't even suspect that it is there at all...
I attribute again this powerful discovery to luck.. Yes one more time, luck... I say that very often since I have started to use UMS.
Here is the chain of thoughts that made me discover this gem.
After dinner, I was reading one of my favorite news website and I have found an article announcing the new release of a memory allocator lib:
https://www.phoronix.com/scan.php?page=n...3-Released
This made me think that I have never really did run a heap profiler on my software. I did attempt to run valgrind on it but for some reason, my app is corrupting valgrind and nothing good can come out of a valgrind run. I suspect that it might be because my app is launching kernel threads through io_uring and valgrind does not like that at all...
Anyway, I did search the net to see if I could find another good heap profiler that will run nicely with my app. I did find heaptrack:
https://github.com/KDE/heaptrack
and it works very well...
This made me discover that my #1 memory allocation spot was inside std:: stable_sort(). I even had no idea that this function was allocating memory. This function is called something like 4 million times every 5 minutes or so. I have replaced calls to stable_sort to something else not allocating. I am currently testing this new improvement... Not sure yet by how much it will improve my reaction time but it should make a difference...
