Markus Dreseler

Here's a patch that prints the number of `iterator++` calls caused by the slow `std::distance`: https://gist.github.com/mrks/ace0cd24acb436b08883e43d00aacedf Note that some of them are not because of our iterator implementations, for example...

Here might be a solution: https://github.com/tzlaine/stl_interfaces Old: ``` #include #include #include #include class Iterator : public boost::iterator_facade { public: Iterator(size_t position) : position(position) {} void increment() { std::cout

Have a look at `mrks/iterators`. I haven't checked if things like `lower_bound` are better now. For now, the overall performance is worse :/

> I might get that wrong, but from my understanding this library saves us to manually add/ensure the required concepts for C++20 functions like std::lower_bound (or std::ranges::lower_bound) to be non-linear....

C++ adds iterator_concept, which fixes the old constraints even outside of the ranges. However, I haven't been able to find these used in the libstdc++ or libc++ masters. I guess...

Could you summarize why it is difficult? My first approach would be to sum it up in `BaseOperatorPerformanceData:walltime` and add a `number_of_executions` there.

The number of executions could be part of the edge label ("Subquery, executed once" and "Subquery, executed n times")

I can't follow. The LQPVisualizer knows about them, so they do leave the evaluator, don't they?

TwoThree thoughts about this: * Once visualized, the subquery execution time should be subtracted from the execution time of the operator that required the subquery. Keep in mind that a...

Hmm, similar, but #63 would also include things like "maximum number of workers to spawn per core" which I don't think should be exposed as a CLI option