4 ms·

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 librarie

by remon 7y ago

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.

leeoniya 7y ago
> 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.
- remon 7y ago
  > 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.

by remon 7y ago

leeoniya 7y ago

> 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.

remon 7y ago
> 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.