08.03.2018 21:56, Emilio G. Cota wrote:
On Thu, Mar 08, 2018 at 14:42:29 +0300, Vladimir Sementsov-Ogievskiy wrote:
Hi Emilio!
Looked through qdist, if I understand correctly, it saves each added (with
different value) element. It is not effective for disk io timing - we'll
have too much elements. In my approach, histogram don't grow, it initially
have several ranges and counts hits to each range.
I thought about this use case, i.e. having a gazillion elements.
You should just do some pre-binning before inserting samples
into qdist, as pointed out in this comment in qdist.h:
/*
* Samples with the same 'x value' end up in the same qdist_entry,
* e.g. inc(0.1) and inc(0.1) end up as {x=0.1, count=2}.
*
* Binning happens only at print time, so that we retain the flexibility to
* choose the binning. This might not be ideal for workloads that do not care
* much about precision and insert many samples all with different x values;
* in that case, pre-binning (e.g. entering both 0.115 and 0.097 as 0.1)
* should be considered.
*/
struct qdist_entry {
double x;
unsigned long count;
};
Let me know if you need help with that.
Thanks,
Emilio
In this case, I'll have to do same bin search (and store same interval
settings) as I already do, on my part, to calculate a parameter for
qdist interface. And I'll have store almost all same data on my part.
So, it doesn't really help. And I need nothing of qdist benefits: I
don't need (and don't want) dynamic allocation of bins on adding an
element or any type of visualization.
--
Best regards,
Vladimir
