Skip to content
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

ddtrace/tracer: don't use UTC() when getting time #1134

Merged
merged 3 commits into from Mar 8, 2022

Conversation

evanj
Copy link
Contributor

@evanj evanj commented Jan 20, 2022

Unix time is defined as the duration since January 1, 1970 UTC.
Calling .UTC() does unnecessary work to convert the "location" field
of the time.Time object. The disassembly shows this new
implementation is a few instructions shorter, but I doubt this will
have any measurable performance impact. This is more about
simplifying the existing code.

I tried adding a test and benchmark for this, but the test was pretty silly, and it is unclear if the benchmark showed a measurable difference.

Unix time is defined as the duration since January 1, 1970 UTC.
Calling .UTC() does unnecessary work to convert the "location" field
of the time.Time object. The disassembly shows this new
implementation is a few instructions shorter, but I doubt this will
have any measurable performance impact. This is more about
simplifying the existing code.
@evanj evanj requested a review from a team January 20, 2022 21:21
@gbbr gbbr changed the title ddtrace/tracer/time.now(): Don't call .UTC() ddtrace/tracer: don't use UTC() when getting time Jan 21, 2022
Copy link
Contributor

@gbbr gbbr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you claim yourself that this doesn't have any measurable impact, why make this change and risk some unexpected regression?

@evanj
Copy link
Contributor Author

evanj commented Jan 21, 2022

It will save future people the time spent trying to figure out if .UTC() actually does anything (it does not). It likely will also be slightly faster: less code means the compiler is more likely to inline it, it will take up less space in cache, etc, but IIRC the difference was something like 60 instructions vs 50 instructions in the disassembly. This is used in the hottest code path for tracing (e.g. twice on each span), so it might not be measurable, but it might help a bit!

If it helps, I could add the test I created that verifies that .UTC does not matter. It does not change the output of UnixNano at all:

func TestUnixUTC(t *testing.T) {
	now := time.Now()
	unix := now.UnixNano()
	unixUTC := now.UTC().UnixNano()
	if unix != unixUTC {
		t.Errorf("now=%#v unix=%#v != unixUTC=%#v", now, unix, unixUTC)
	}
}

@dianashevchenko
Copy link
Contributor

dianashevchenko commented Jan 21, 2022

@gbbr I might be wrong but if we remove .UTC(), and someone decides to look at all the spans from all the instances around the world within a specific timeframe, won't that be faulty? 🤔

@evanj
Copy link
Contributor Author

evanj commented Jan 21, 2022

@dianashevchenko .UnixNano is defined as "nanoseconds since January 1st 00:00:00 UTC. It is already timezone independent. The value does not change when the timezone of the system changes. The test that I posted in my comment passes, which shows that calling .UTC() does not change the value of .UnixNano().

I should add: I'm totally okay with this change being rejected. I just hate code that does nothing, and find this excess .UTC() to be confusing.

Copy link
Contributor

@gbbr gbbr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. It makes sense. Thanks for explaining.

@Julio-Guerra Julio-Guerra added this to the 1.37.0 milestone Mar 8, 2022
@Julio-Guerra Julio-Guerra merged commit 5b43087 into v1 Mar 8, 2022
@Julio-Guerra Julio-Guerra deleted the evan.jones/time-now branch March 8, 2022 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants