-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(profiling): keep string cache data alive longer #2668
Conversation
BenchmarksBenchmark execution time: 2024-06-12 14:33:43 Comparing candidate commit c72a081 in PR branch Found 1 performance improvements and 0 performance regressions! Performance is the same for 26 metrics, 9 unstable metrics. scenario:walk_stack/1
|
We still have to re-establish the link in the run time cache, but the string set itself will keep the sets and data alive.
30f0e72
to
5d6e76c
Compare
Now that the copy/paste issue and the unrelated sigsegvs have been fixed, this is looking much better. I plan to do some manual testing to be more confident, but I'm marking this as ready for review. We should probably release a libdatadog version before merge, though, and use that rather than the git revision hash. |
492c6e8
to
b1ee71e
Compare
f1a2226
to
8b968fb
Compare
b11496c
to
c7a7d7c
Compare
A slow ramp up to 4 MiB could _look_ like a memory leak. However, a slow ramp to 2 MiB is probably going to look like it's within normal operating ranges.
Description
PROF-9796
At the high-level, there are two wins here:
Details
This uses the new allocators in libdatadog to build a
StringSet
, and drops the old string table from the code. Like the newStringTable
in libdatadog v9, the string data for theStringSet
is held in an arena. However, it doesn't track insert order, nor hand out ids. It returns references to interned data instead, like a regular set.We store
ThinStr<'a>
s in the runtime cache, asusize
s. This bit is unsafe because the lifetime of the cache doesn't fit nicely in the borrow checker's semantics. However, the implementation guarantees that the data lives long enough.The run time cache is empty on each request, but the table data is still around. So we'll re-establish links to the cache to the data, but we don't have to rebuild the set structure as much compared to the previous implementation
If the allocators powering the string set report memory over 2 MiB at the end of a request, then the string set will start over. This particular number was chosen because it is the same size used for the chunk size of the chain allocator powering the set. The idea is that if we have more than one chunk, then maybe we're too big. We also don't want to look like a memory leak, and sizes over 2 MiB may start to look like we're leaking memory as we slowly use more and more.
Reviewer checklist