On 2019-05-20 12:48, Lars Knoll wrote:
So you should give people the option to implement their 5% code that’s
performance critical in a fast way and make it as easy as possible for
them to implement the remaining 95%.
I fully agree. The problem is that Qt as a library doesn't know where
these 5% are in a given user's code, so Qt needs to assume of any of its
functions that it may become the bottleneck in _some_ user's
application. One might need to parse megabytes of JSON, the other might
want to create 1000s of UUIDs per second. If Qt has ineffcient APIs,
then the user cannot fix her performance problem, or needs to do so
using a library other than Qt. Only by providing efficient APIs do we
empower the user to fix her performance problem, while staying in Qt.
While it can be reasonably expected that users will only create O(100)
widgets, any such limits simply cannot be assumed on any container.
I already cited the QRegion problem where there were multiple instances
of
if (r.rectCount() == 1) {
use(r.boundingRect());
} else {
for (auto rect : r.rects())
use(rect);
}
Nobody writes code like that unless it's needed. This all went away when
QRegion became iterable. Now
for (auto rect : r)
use(r);
is maximally performant for all states of QRegion, the user code is
simpler, and all cases are faster than the fastest case before.
All I'm saying is that there are tons of examples (QGradient) where the
use of an owning container in the API is just a very bad idea and limits
the implementor's freedom and/or performance. E.g. QGradient could have
inline storage for two or three stops to avoid allocating memory for the
most-common cases. I mean, QPainter is full of (QPoint *, int nPoints)
APIs that surely were added just for performance. Ditto for QString,
btw. Nowadays, with views, we can have the same API, but have it accept
many owning containers transparently. I'm not saying that there must be
no owning containers in the API. But there is a lot of low-hanging fruit
out there.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
