[Development] Views

[Mutz, Marc]

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