Road to 1.0.

[mikeb01]

The C implementation of HDR Histogram is fairly stable now, but there are a number of pending changes that should really be in place before making it a 1.0 version. The 3 outstanding features I think that should be required are:

• packed arrays.
• resizable counts.
• double support.

However to complete this I think I would need to break the API to some degree. Mostly because the main struct is defined in the header which makes changing it potentially a breaking a change. To make future changes more flexible, I would like to make hdr_histogram an opaque point and hide the internal structure.

Feedback on how this may impact users would be appreciated. E.g. are there any users depending on stack allocation of the hdr_histogram?

Please reply to this issue if you have any issues or suggestions regarding the implementation for the next major revision of the HDR Histgoram.

[ahothan]

This library is used by the Trex traffic generator (c++) and it does not rely on stack allocation.
The allocation is done by:

(private member of a class):
// Hdr histogram instance
hdr_histogram *m_hdrh;

(allocation):
int res = hdr_init(HDRH_LOWEST_TRACKABLE_VALUE, HDRH_HIGHEST_TRACKABLE_VALUE,
HDRH_SIGNIFICANT_DIGITS, &m_hdrh);

So should work fine if you make the struct opaque.

[natoscott]

The library is also used in the Performance Co-Pilot suite, and it's the same situation there that @ahothan described - no problem with making the structure opaque.

[shuhaowu]

one potential use case of hdr histogram is to use it in real-time software, where worst-case latency must be known. An opaque pointer is likely fine, but recording values shouldn't result in some sort of internal resizing/allocation to enable that use case.

That said, I'm still evaluating HDR histogram in soft/hard real-time context, so I may be speaking too fast...