Henry Robinson has posted comments on this change.
Change subject: IMPALA-4187: Switch RPC latency metrics to histograms
Patch Set 2:
Perf results are in the commit msg now.
PS2, Line 179: int32_t
We typically don't use uint (not consistent in that, unfortunately).
PS2, Line 181: 3
> nit: I've previously learned that it's a good practice not to use "magic" c
Happy to add a comment.
PS2, Line 181: SIXTY_MINUTES_IN_MS
> If I understand correctly, this means the longest RPC call could be 60min.
Sure, but what's the drawback of having 60 minutes be the upper bound?
PS2, Line 37: highest_trackable_value, num_significant_digits
> would it be worth to store those in HistogramMetric?
What would be the benefit? They're already stored in HdrHistogram.
> There's no shared state access before this line. Worth locking from here?
> And releasing the lock here?
PS2, Line 70: histogram_->Increment(val);
> On an unrelated note, I looked through the implementation of HdrHistogram a
I'm not sure I follow - HdrHistogram is thread-safe (at least per the class
comment). The reason we have locks here is to protect access to the pointer to
the histogram object.
PS2, Line 107: boost::scoped_ptr<HdrHistogram> histogram_;
> I know we had a scoped_ptr vs unique_ptr discussion thread recently, but it
Yes, I think that was the result of the conversation so far. scoped_ptr for
objects whose ownership will never change.
To view, visit http://gerrit.cloudera.org:8080/4516
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Owner: Henry Robinson <he...@cloudera.com>
Gerrit-Reviewer: Henry Robinson <he...@cloudera.com>
Gerrit-Reviewer: Juan Yu <j...@cloudera.com>
Gerrit-Reviewer: Sailesh Mukil <sail...@cloudera.com>