-
Notifications
You must be signed in to change notification settings - Fork 104
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
tracers: store startup created tracers the same way as user created #316
tracers: store startup created tracers the same way as user created #316
Conversation
To simplify the understanding of tracer registration and fetching this removes the separation between tracers registered on startup for each application and those registered by a user or other code at runtime. Now there is a map to lookup the application name for a module which is used to lookup the tracer, instead of before where the map lookup actually got the tracer (meaning the tracer record was duplicated and stored for every module!). This means a user registering a tracer can override the tracer registered at startup for an application name if they use the same name, but I think this is sort of expected behavior so not an issue. The change shouldn't effect much, if any, existing user code since it almost always that tracers are fetched behind the scenes by the macros.
8125c64
to
8709fc2
Compare
Codecov Report
@@ Coverage Diff @@
## main #316 +/- ##
==========================================
- Coverage 38.60% 38.47% -0.14%
==========================================
Files 50 50
Lines 3463 3462 -1
==========================================
- Hits 1337 1332 -5
- Misses 2126 2130 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Last time this changes, I swear. Originally it wasn't done this way because it requires a second lookup (first find the application name, then use that as the key for the persistent term where the tracer is stored). But I'd argue that those are fast enough and the user is able to store the returned tracer in a variable and use it if there are times they want to remove any lookup overhead in usage. This extra lookup saves from having to store the tracer record duplicated for every single module and it removes the separation between tracers created by a user and those created at SDK startup. This important for when Tracers become configurable and it would be really confusing to deal with two sets of tracers when going to configure how one works. |
Note that this shouldn't effect any code since they should all be using the macros that hide it. And I think they all do now. |
To simplify the understanding of tracer registration and fetching
this removes the separation between tracers registered on startup
for each application and those registered by a user or other code
at runtime.
Now there is a map to lookup the application name for a module
which is used to lookup the tracer, instead of before where the
map lookup actually got the tracer (meaning the tracer record was
duplicated and stored for every module!).
This means a user registering a tracer can override the tracer
registered at startup for an application name if they use the same
name, but I think this is sort of expected behavior so not an issue.
The change shouldn't effect much, if any, existing user code since
it almost always that tracers are fetched behind the scenes by
the macros.