Performance Improvements - #61
Open
Ipiano wants to merge 2 commits into
Open
Conversation
added 2 commits
July 14, 2026 10:37
The contended-lock path spun on try_lock with 1us sleeps in between. The kernel's default timer slack (50us) inflates each of those sleeps to ~50us, so under multi-threaded allocation pressure every contended malloc/free stalled far longer than the critical section it waited for. Use a timed_mutex and wait on it directly; the 1ms timeout only bounds how long a pending shutdown request can go unnoticed, preserving the deadlock-avoidance behavior of the old loop.
Unwinding the stack on every allocation is the dominant per-thread cost of tracking, and it scales linearly with stack depth. Allow capping the captured depth below the fixed MAX_SIZE of 64 via the HEAPTRACK_UNWIND_DEPTH environment variable, exposed through the new --unwind-depth option of the heaptrack script. The default stays 64. Invalid values are rejected with a warning rather than clamped, so a typo cannot silently produce single-frame traces.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background - I run heaptrack on an embedded linux device that has a similar amount of horsepower to later Raspberry Pis. The application I'm working on is a Qt-QML application with custom 3d rendering and some pretty heavy data processing - you might imagine there's quite a bit of heap allocation going on. After making these changes, I'm able to run the project without the whole thing grinding to an unusable halt.
Two changes here, one per commit
futexwait-for functionality instead of a try-lock, wait loop improves performance in heavily concurrent applications. PThreads is able to do a better job waking up threads quickly when we let it handle the try-then-wake loop like this; and the strategy that the kernel uses to schedule short sleeps can actually cause a "sleep 1 microsecond" to end up being closer to 50 us due to the timer coelescing behaviors, depending on your kernel settings and process priority.perfto record a trace of my process while it's beingheaptracked shows that the stack unwind is the most expensive part of the heaptrack overhead. I don't need a full 64 frames of the stack to figure out what's going on in most cases, and cutting it down to 32 or 16 improves performance massively.