These are chat archives for HdrHistogram/HdrHistogram

11th
May 2016
Lee Campbell
@LeeCampbell
May 11 2016 05:45
Thanks for the review @ahothan . I will add this list of improvements to the issues list.
Gil Tene
@giltene
May 11 2016 06:10
@ahothan @LeeCampbell : Which encapsulation were you asking for history on?
For the encoded histograms: it's basically a nested encapsulation. There is a straightforward encapsulation for non-compressed (as in no zlib) histograms, and then there is a (straightforward in itself) compressed histogram encapsulation that surrounds it. You may have noticed that the cookie values for each (both the compressed and non-compressed) were carefully chosen so that when they are base64 encoded in a file or stream, the text ends up beginning with "HIST". This lets you visually identify a string as bobbly-good as a [likely] encoded histogram.
Gil Tene
@giltene
May 11 2016 06:17
For the file/stream lines: The need for the interval time is straightforward to understand, I imagine, and so is the needs for the actual histogram. The max value is there for human readability and ease of very-simple-parsing for timeline plots. I.e. if you want to just plot a max-value-per-interval chart (which is very useful next to a percentile distribution chart. E.g. in jHiccup-style plots), you only need the max value, and that can be scraped out of this log format with awk, without needing to decode histograms.
For the human readability, it is common to look at a log file and scan for the max time visually.
Alec
@ahothan
May 11 2016 17:43
@giltene would you be open to have a place to store HdrHistogram doc/spec that are implementation independent? Perhaps a doc git repo? @LeeCampbell doc could be moved there (instead of inside the .NET repo). The info you provided on how the encaps were defined can be added to that doc.