from a perf perspective it's more like excluding the mirrors and windshield wipers. the amount of measuring [of label text] that might be required for this bench is absolutely dwarfed by the time needed to render the data; it's a rounding error.
> After having a look at the code and the list of "non-features"
it's quite obvious that you didn't understand the code you looked at, because you would have noticed that the bench code does not use any of the "non-features" (in any lib).
you should present stronger evidence that the benchmarks are BS.
And you should calm down a bit. I was referring to your benchmark hitting exactly the functional scope of your library while it's invoking more generic libraries that by extension have to do more work for the same functional result. Based on average feedback here that position is supported by other real world users of these sorts of libraries.
As for label rendering/measuring; choose. Either it's a rounding error in perf in which case don't claim it's a performance hog. Or claim it's a performance hog and don't call it a rounding error to support an argument.
> I was referring to your benchmark hitting exactly the functional scope of your library while it's invoking more generic libraries that by extension have to do more work for the same functional result
ok that's fair but that overhead is immense, and you end up paying it regardless of whether it's needed or not. obviously uPlot is opinionated and is fast because of this. i'm not here to pry anyone's favorite charting lib from them. all i'm showing is what's possible if you dont need to be generic and cater to everyone.
i dont think i ever said label measuring/collision detection is a performance hog. compared to the work of doing the plot itself, it's insignificant. avoiding that work is more of a code size and complexity reduction for uPlot, rather than a perf opt.
how else could i possibly present a benchmark of uPlot without limiting the alternatives to its own functional scope? that would be like comparing 0-60 on a formula 1 vs a mini-van and claiming the results to be invalid because the minivan can fit 7 people but the formula 1 cannot. that fact is made abundantly clear upfront.
> i dont think i ever said label measuring/collision detection is a performance hog. compared to the work of doing the plot itself, it's insignificant. avoiding that work is more of a code size and complexity reduction for uPlot, rather than a perf opt.
Okay, fair enough
> how else could i possibly present a benchmark of my lib without limiting the alternatives to its own functional scope?
Can't think of a good way to do that. That's why I don't think your benchmark is BS or in bad faith. All I was trying to say (but clearly didn't communicate effectively) is that the value of the benchmark is limited as comparison data for me and I assume others because it's not really comparing the same end-to-end functionality if in the vast majority of cases the implementor would have to manually add some things that it doesn't do out of the box (thereby burning the same CPU cycles you're avoiding).
Anyway, let's close this thread. The above footnote aside it looks like a super clean library. Well done.
> After having a look at the code and the list of "non-features"
it's quite obvious that you didn't understand the code you looked at, because you would have noticed that the bench code does not use any of the "non-features" (in any lib).
you should present stronger evidence that the benchmarks are BS.