-
Notifications
You must be signed in to change notification settings - Fork 140
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
⚡️ [RUM-2917] optimize getNodePrivacyLevel by adding a cache #2579
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ✔️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
/to-staging |
🚂 Branch Integration: starting soon, merge in < 0s Commit f144a6f7a9 will soon be integrated into staging-05. This build is going to start soon! (estimated merge in less than 0s) Use |
… into staging-05 Co-authored-by: Benoît Zugmeyer <[email protected]>
🚂 Branch Integration: This commit was successfully integrated Commit f144a6f7a9 has been merged into staging-05 in merge commit cf710c7d9f. Check out the triggered pipeline on Gitlab 🦊 |
…ode-privacy-level
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2579 +/- ##
=======================================
Coverage 92.82% 92.83%
=======================================
Files 232 232
Lines 6760 6768 +8
Branches 1486 1489 +3
=======================================
+ Hits 6275 6283 +8
Misses 485 485 ☔ View full report in Codecov by Sentry. |
Motivation
A customer reported that
getNodePrivacyLevel
was a big performance bottleneck on their application when the devtools were open. On our side, we didn't observe a huge performance impact caused by this function (with or without devtools open), but still find a way to optimize it, which might help the customer case.Changes
Cache the node privacy level when processing mutations. The cache is local to the
proccessMutations
function so we don't have to implement a complex way to invalidate it. Even with this simple cache, we observed a nice speedup while processing mutations (from ~10ms to ~1.5ms in a specific case on the Datadog App)Testing
I have gone over the contributing documentation.