Swap UUID generation to be lazy #2131
Conversation
|
hey @bayangan1991 thanks for the PR, that's a valuable observation. I'm actually working on some more general 'make the SDK as low overhead as possible', so I'll take this into account for that. I'll keep this PR open for now and come back to you in some time on if we take this in or I incorporate avoiding UUID / span creation in some other way. |
There was a problem hiding this comment.
hey @bayangan1991 I think we'll take this in!
can you fix the one type signature for 2.7?
sentry_sdk/tracing.py
Outdated
| return self._span_id | ||
|
|
||
| @span_id.setter | ||
| def span_id(self, value: str) -> None: |
There was a problem hiding this comment.
| def span_id(self, value: str) -> None: | |
| def span_id(self, value) -> None: |
our tests need to pass on 2.7 as well
There was a problem hiding this comment.
Ah yeah ok. Force of habit. I dropped the extra -> None as well.
|
ty! I'll merge this on monday after some quick sanity testing on django |
|
im gonna reopen this separately since we dont have rights for the fork |
Running py-spy while the sentry sdk in a django project shows that there is a lot of time spent generating un-used uuid.
This PR simply takes the same UUID format and puts it's behind some custom getter and setter code.
Just in a fairly large django project start I saw number of UUID's used go from several hundred thousand to hundreds.