These are chat archives for HdrHistogram/HdrHistogram

Aug 2015
Gil Tene
Aug 01 2015 02:16
@ahothan @mikeb01 : While I think the C code is probably right, it's worth noting that I've refactored the iteration code in the Java code a few versions back, and it is simpler now [I think the C code ported from my original Java logic]. Basically, instead of incrementing buckets and sub-buckets separately, the new code just increments indexes and uses valueFromIndex() to determine currentValueAtIndex and nextValueAtIndex. This way there is no need to check or do anything anything about crossing bucket boundaries and incrementSubBucket simply increments an index...
Michael Barker
Aug 01 2015 07:40
@giltene I'll have to have a look. The C implementation was significantly different from the Java one when I first wrote it mostly as the Java version used inheritance to handle reuse between the iterator types whereas the C implementation uses a delegation-like approach. Also I don't track next or previous values, just the current ones.
Aug 01 2015 18:50
@mikeb01 /@giltene, looking at the V1 encoding, it looked odd to me that you decided to put another payload length in the compressed part
typedef struct attribute((packed))
int32_t cookie;
int32_t payload_len;
int32_t normalizing_index_offset;
int32_t significant_figures;
int64_t lowest_trackable_value;
int64_t highest_trackable_value;
uint64_t conversion_ratio_bits;
int64_t counts0;
} _encoding_flyweight_v1;
size_t encoded_size =
sizeof(_encoding_flyweight_v1) + (sizeof(int64_t) * counts_limit);
encoded->payload_len = htobe32(encoded_size);
The decompress() function will return the same value. Was there any particular reason to add that field?