-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
add millisecond duration encoder #773
add millisecond duration encoder #773
Conversation
Codecov Report
@@ Coverage Diff @@
## master #773 +/- ##
==========================================
+ Coverage 98.19% 98.19% +<.01%
==========================================
Files 42 42
Lines 2271 2275 +4
==========================================
+ Hits 2230 2234 +4
Misses 33 33
Partials 8 8
Continue to review full report at Codecov.
|
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.
Thanks for the contribution @caibirdme
This change looks good to me, just needs some tests. Can you please add tests for this change?
Ok, no problem! I'll add those testcases soon |
@prashantv I'v added the test case |
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.
Thanks for adding tests
One thing I noticed while looking at this again is that we may be inconsistent in whether we're encoding a float or an integer.
For example:
SecondsDurationEncoder
uses a floating-point number of secondsEpochMilliEncoder
uses a floating-point number of seconds since the epoch for times
Given that, I think it makes more sense for MillisDurationEncoder
to also encode a floating point value.
If we want to encode an integer value, we might want to add a suffix like SecondsIntDurationEncoder
and MillisIntDurationEncoder
.
Open to other ideas too, but want to make sure we're consistent.
@prashantv Well, I understand that, but if we just use float64, something like
|
Constructor will help if you manually create the encoder, but it won't be as easy to use when unmarshalling a configuration from a YAML file. For your use-case, do you want to control the precision, or would you prefer to use int vs float? |
Actually, I don't care about the precision, what I want is just how many milliseconds the operation costs. 30 or 30.05 are both ok for me, but 30.00005 smells bad. But as the test case shows, all the other encoder could show how nanoseconds it costs(1.0000005s 1.0000005 1000000500),I don't know if something like 1.02 will bring some inconsistencies. But really, I think float with just two decimal places is better. When people choose ms encoder, nobody cares about the nanoseconds |
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.
I discussed this offline with @abhinav and we decided that we should keep it simple: In general, if you ask for X, the granularity you probably care about is X.
The millis encoder should use int, so you can keep this change as-is.
Can you please rename the method to for consistency, otherwise, this change looks good.
// MillisDurationEncoder serializes a time.Duration to an integer number of | ||
// milliseconds elapsed. | ||
func MillisDurationEncoder(d time.Duration, enc PrimitiveArrayEncoder) { | ||
enc.AppendInt64(d.Nanoseconds() / 1e6) |
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.
enc.AppendInt64(d.Nanoseconds() / 1e6) | |
enc.AppendInt64(d.Milliseconds()) |
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.
the d.Milliseconds() is a new API only for go1.13+
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.
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.
Good point, we can migrate to it once we drop support for 1.12. This is good for now, thanks.
The CLA bot is blocked on user liudeen -- if that's an old username you no longer use, can you squash your commits into one owned by the new user |
1f89259
to
f7f9679
Compare
make ms encoder compatible for go version <=1.13.0 & add testcase for ms encoder change name of ms encoder
f7f9679
to
2b89bdd
Compare
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.
Thanks for the contribution @caibirdme!
make ms encoder compatible for go version <=1.13.0 & add testcase for ms encoder
Since network requests are always in milliseconds level, if procTime shows in seconds, it may look like
0.003
, to many zeros. While if the procTime shows in nanoseconds, it may look like12312312323
, too big to identify. So it'd be better to support milliseconds encoder, something like30.5
, pretty intuisive.