-
Notifications
You must be signed in to change notification settings - Fork 524
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
Use Prometheus fast regexp #4329
Conversation
BenchmarkBlockTraceql was adjusted to:
Benches!
|
To respond to my own question. I believe the implementation is fine as is. It would be preferable to share the memoization, but this is such a small percentage of total allocs and cpu and the solutions to sharing memoization are so gnarly that I believe this path is the best for now. Perhaps some future developer can find a way to cleanly share memoization between the fetch layer and engine. |
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.
Thank you for updating the docs!
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 nice improvement just small nit
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
Co-authored-by: Kim Nylander <[email protected]>
Signed-off-by: Joe Elliott <[email protected]>
c2842d1
to
fb3e0f9
Compare
What this PR does:
Uses prometheus' fast regexp package instead of the standard go regexp for performance. This does create a breaking change in Tempo as prometheus regexps are always anchored.
This
{ span.foo =~ "bar" }
used to be a substring search. After this PR it will be an exact match.My primary concern with this PR is that we are now memoizing at the fetch and engine layers. This will cause extra allocations for certain queries. Should we remove this for the engine layer to match current behavior?
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]