>Qt must have acceptable performance for end user applications to be able to >have >acceptable performance at all - whether or not it is a priority to those >developers.
I write an application that has two performance requirements: 1. It must complete execution in 1 minute. 2. It must not run out of memory. If I use QList in my application instead of QVector, and it still passes both requirements tests, then whether QList is as bad as Marc says it is (I have no reason to doubt him) makes no difference. If you replace QList with QVector and rename it QList and my application still passes both tests, then not only will I not complain, I won't know about it unless I reread the documentation. So if we can make that guarantee, then let's just make the switch. Aside: I'm from that bygone era long before Qt, when a "list" in computer programming always meant linked list. A sequence of contiguous data entries was an array. There were no exceptions. So even now, after using QList for more than a decade, I still forget that it's not a linked list. martin ________________________________ From: Development <[email protected]> on behalf of Robin Burchell <[email protected]> Sent: Monday, March 20, 2017 1:13:23 PM To: [email protected] Subject: Re: [Development] QList Hi Philippe, On Mon, Mar 20, 2017, at 09:28 AM, Philippe wrote: > >>Even our API guidelines stipulate that you should make common things easy > >>and > >>not-so-common things possible. Sharing is _not_ common and it need not be as > >> easy as common tasks. I > > Maybe for you, but in my works, sharing _is_ common, convenient and safe. > And overal usage of COW is one of the concept that makes Qt stand apart. > From my POV, COW largely pay off its minimal performance cost. > When performance is a high priority, _an uncommon case_, then using > alternate containers is always possible and we don't need Qt for this. I don't know your background, but let's assume you are primarily a user of Qt (thus: an application developer of some kind), you may consider performance to be unimportant, or important only in isolated areas of your application. Consider, however, the point of view from many of the people on this list: as Qt uses itself in its own implementation, Qt must have acceptable performance for end user applications to be able to have acceptable performance at all - whether or not it is a priority to those developers. A few concrete examples of where data types matter a lot: signal connections (involves storing a bunch of data), QObject (particularly QObject::children, as already mentioned), event handling from the operating system (or the application itself: the event posting mechanism in QCoreApplication)... > And when size matters, have this in mind: > > sizeof(std::vector<int>) == 32 > sizeof(QVector<int>) == 8 > sizeof(QList<int>) == 8 To provide a more helpful response than Marc's: I assume that you are aware that the Qt types just contain a pointer to a thing which contains the actual data (unlike std::vector), right? That is, QVector<int> is actually (snipped from source): template <typename T> class QVector { typedef QTypedArrayData<T> Data; Data *d; } Where QTypedArrayData<T> is a QArrayData, which is: struct Q_CORE_EXPORT QArrayData { QtPrivate::RefCount ref; int size; uint alloc : 31; uint capacityReserved : 1; qptrdiff offset; } If I'm adding it up right, this gives me a total cost of 32 bytes on my system. Although the real cost is actually higher I'd guess, due to the two being allocated in separate pieces (given that malloc usually has some kind of book-keeping overhead). Robin -- Robin Burchell [email protected] _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
