On Friday 10 July 2015 10:05:40 Curtis Mitch wrote:
consider Q_DECLARE_METATYPE with the appropriate flag (yes, even
I'm guessing that you meant to write Q_DECLARE_TYPEINFO here?
Yes, _TYPEINFO is what I meant.
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB
It might be more instructive to describe these by the effects they have:
On Friday 10 July 2015 10:05:40 Curtis Mitch wrote:
Q_PRIMITIVE_TYPE
Imples Q_MOVABLE_TYPE. In addition, the default ctor is replaced by memset(0)
and the dtor call with nothing.
Q_MOVABLE_TYPE
Has nothing to do with
Hi,
I'll never manage to eradicate inefficient QLists if people continue to add
new ones :) So here are some things I'd like _everyone_ to watch out for in
reviews and mercilessly -1:
- using QList
- not using Q_DECLARE_TYPEINFO
Let me qualify that a bit: QListC is a _very_ bad idea for
PROFINET would be nice... :)
it is very complex... but wide used in industrial automation...
greetings
jan
Am 03.07.2015 um 12:13 schrieb Turunen Tuukka:
Hi,
As you are probably aware, we are developing a new Qt SerialBus
module. Target is to have a technology preview in Qt 5.6
-Original Message-
From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
[mailto:development-bounces+mitch.curtis=theqtcompany.com@qt-
project.org] On Behalf Of Marc Mutz
Sent: Friday, 10 July 2015 11:04 AM
To: development@qt-project.org
Subject: [Development] HEADS
Il 10/07/2015 11:54, Smith Martin ha scritto:
Then I don't see why it is so inherently inefficient. The QList entry is allocated on
the heap anyway. Doesn't QListC just allocate a bigger entry? And if I don't
have the C object stored anywhere else, it has to be somewhere, so why not keep it in
-Original Message-
From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
[mailto:development-bounces+mitch.curtis=theqtcompany.com@qt-
project.org] On Behalf Of Giuseppe D'Angelo
Sent: Friday, 10 July 2015 12:05 PM
To: Smith Martin; development@qt-project.org
Do you mean that if I declare this:
typedef QListParsedParameter ParsedParameterList;
where ParsedParameter is:
struct ParsedParameter {
bool qPrivateSignal_;
QString dataType_;
QString name_;
QString defaultValue_;
ParsedParameter() :
Le vendredi 10 juillet 2015 à 10:12 +, Curtis Mitch a écrit :
(*) not movable, or bigger than a void*. And user-defined types are not
movable by default (they're complex). And if we forget
Q_DECLARE_TYPEINFO on public types, we can't add it back because it's
binary incompatible.
1) you put pressure on the memory allocator, by asking it to allocate on
the heap each individual C object you put in the list. Every single
allocation has a cost, plus the overhead you need for bookkeeping, plus
the costs of getting your memory fragmented, etc.;
This pressure on the memory
On Friday 10 July 2015 11:35:34 Smith Martin wrote:
1) you put pressure on the memory allocator, by asking it to allocate on
the heap each individual C object you put in the list. Every single
allocation has a cost, plus the overhead you need for bookkeeping, plus
the costs of getting your
Calling malloc/free is not a cheap operation, when you profile most Qt
applications, you'll find these functions nearly always in the top 10, often
even the top 5, of functions where most time is spent.
But, Marc made QVector for QList swap in qdoc several weeks ago for the same
kind of thing,
On Friday 10 July 2015 13:29:30 Marc Mutz wrote:
On Friday 10 July 2015 12:18:04 Smith Martin wrote:
...it will create each list entry as a QListParsedParameter* even
though I told it not to do that?
Yes. But you told it to do that. You used a _list_.
Ok, I take the bait:
QList is
Maybe it's just me, but I'm still not understanding your explanation, and I
don't think you are answering my question:
I have a struct C which is bigger than a pointer. I declare QListC. Does your
explanation mean that sometimes (most of the time, in fact), the list will
become an array of C*
On Friday 10 July 2015 12:18:04 Smith Martin wrote:
...it will create each list entry as a QListParsedParameter* even though
I told it not to do that?
Yes. But you told it to do that. You used a _list_.
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG,
Il 10/07/2015 12:12, Curtis Mitch ha scritto:
How is it binary incompatible?
Because the code produced by QListC (which is inlined) is incompatible
if C becomes a good type (from a bad one) or viceversa.
The code for a bad C involves allocating every C object on the heap,
putting the
On 10 Jul 2015, at 14:58, Marc Mutz marc.m...@kdab.com wrote:
On Friday 10 July 2015 13:37:40 Andreas Aardal Hanssen wrote:
QListQImage.
You just proved my point. sizeof(QImage) sizeof(void*). If even you as a
long-time Troll don't understand what QList actually does, there's a problem.
Can we please avoid turning this thread into why is QList bad?
Sorry, you're the one who said it's bad; I'm quite happy with it. I'm asking if
QListC becomes QListC* even if I declare it as QListC.
martin
From:
On Friday 10 July 2015 13:35:34 Smith Martin wrote:
1) you put pressure on the memory allocator, by asking it to allocate on
the heap each individual C object you put in the list. Every single
allocation has a cost, plus the overhead you need for bookkeeping, plus
the costs of getting your
On Friday 10 July 2015 11:54:16 Smith Martin wrote:
Then I don't see why it is so inherently inefficient. The QList entry is
allocated on the heap anyway. Doesn't QListC just allocate a bigger
entry? And if I don't have the C object stored anywhere else, it has to be
somewhere, so why not keep
On Friday 10 July 2015 12:24:35 Smith Martin wrote:
Yes. But you told it to do that. You used a _list_.
But I told it to make a lis of C, not a list of C*.
You told it to make a list of C and it chose to implement it as an array of C*
--
Marc Mutz marc.m...@kdab.com | Senior Software
On 10 Jul 2015, at 14:24, Marc Mutz marc.m...@kdab.com wrote:
That just goes to show how bad of an influence QList has. But it never hid
its
design, and, indeed, the default container in Qt 3 was QValueList, which
actually *was* a doubly-linked list. Why Qt always nominates a list as the
On Friday 10 July 2015 12:45:51 Bo Thorsen wrote:
I'm a big fan of naming things in ways that says what I'm looking at. To
me this suggests that we should rename this one to Q_MEMCOPIABLE_TYPE or
something else.
The only established name that I know of for that concept is
On Friday 10 July 2015 12:20:55 Smith Martin wrote:
I'm asking if QListC becomes QListC* even if I declare it as QListC.
And I said in the initial mail:
On Friday 10 July 2015 11:03:49 Marc Mutz wrote:
I won't give you the whole story (google QList harmful for that)
Which you clearly haven't
I think the impedance mismatch here is that you use list to mean the same
thing as array or vector (in STL terms, not mathematically) while I only
use it to mean linked list, in accordance with the STL.
I actually just mean it's a list, and I don't care how it is implemented. I can
see that it
On Friday 10 July 2015 14:19:54 Andreas Aardal Hanssen wrote:
On 10 Jul 2015, at 14:58, Marc Mutz marc.m...@kdab.com wrote:
On Friday 10 July 2015 13:37:40 Andreas Aardal Hanssen wrote:
QListQImage.
You just proved my point. sizeof(QImage) sizeof(void*). If even you as
a long-time
Smith Martin schreef op 10-7-2015 om 13:27:
I think the impedance mismatch here is that you use list to mean the same
thing as array or vector (in STL terms, not mathematically) while I only
use it to mean linked list, in accordance with the STL.
I actually just mean it's a list, and I don't
-Original Message-
From: giuseppe.dang...@kdab.com [mailto:giuseppe.dang...@kdab.com]
Sent: Friday, 10 July 2015 12:22 PM
To: Curtis Mitch; Smith Martin; development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use
Q_DECLARE_TYPEINFO
Il 10/07/2015 12:12,
On Friday 10 July 2015 12:48:26 Smith Martin wrote:
Calling malloc/free is not a cheap operation, when you profile most Qt
applications, you'll find these functions nearly always in the top 10,
often even the top 5, of functions where most time is spent.
But, Marc made QVector for QList swap
On 2015-07-10 06:37, Smith Martin wrote:
ok, thanks, G. That explains it. And then there is the further point that it
is unwise to use Q_DECLARE_TYPEINFO to declare C to be good in this case.
What was the reasoning there?
It really depends. The issue with Q_DECLARE_TYPEINFO is that
-Original Message-
From: development-bounces+alexander.blasche=theqtcompany.com@qt-
project.org [mailto:development-
bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of
Tom Isaacson
Sent: Friday, 10 July 2015 11:13
To: development@qt-project.org
Subject: Re:
On Friday 10 July 2015 14:48:26 Smith Martin wrote:
but I generally don'[[t try to optimize until I have a working model.
This is not premature optimisation. This is avoiding premature pessimisation
(google it!).
QVector has exactly the same API these days as QList (except that QVector
There are a lot more commands in NMEA2000 than just position. As far as I can
see QNmeaPositionInfoSource just allows you to enter data you've already
parsed, there's no bus support there.
Tom Isaacson
-Original Message-
From: Blasche Alexander
On Friday 10 July 2015 17:00:22 Smith Martin wrote:
This is not premature optimisation.
It is premature because the entire structure will be removed.
I'm sorry, my static checking code doesn't yet read my mind, much less other
people's. :)
--
Marc Mutz marc.m...@kdab.com | Senior Software
On Friday 10 July 2015 13:26:47 Giuseppe D'Angelo wrote:
3) you kill caching, as potentially every single access will result in a
cache miss (even in the common scenario of a simple forward iteration
over your list);
Even if it isn't a cache miss now, it might become later as there will be
On Friday 10 July 2015 15:22:13 Milian Wolff wrote:
In this case, qdoc creates a QListParsedParameter as it parses a
function
signature. All the calls to malloc occur one right after another, and then
the list is complete. There hasn't been any intervening heap work, so all
these
You are talking about a specific code path in qdoc, while this thread is about
QList in general. This does not help at all.
But that was the point. The argument is that QListC should not be used at
all, but in the specific code path where it is being changed, it was ok.
And apparently QVector
On Friday 10 July 2015 17:01:04 Smith Martin wrote:
And apparently QVector has the same API as QList now, so why don't we
deprecate QList. Let it always create a QVector.
Because it's used in our API and we cannot deprecate such large chunks of it.
--
Thiago Macieira - thiago.macieira (AT)
I’m surprised nobody has mentioned that, because of the private data nature of
most Qt classes, they are a) already allocating the private data object on the
heap all the time and incurring all that overhead and memory allocation
badness, and b) are essentially a pointer to an object already —
On Friday 10 July 2015 09:50:40 Thiago Macieira wrote:
A QList of 8 elements of 16 bytes each occupies:
8 * sizeof(void*) + sizeof(QListData) + overhead = 8 * 8 + 16 + 16
8 * (sizeof(element) + overhead) = 8 * 32
-
352 bytes (6 to 19 cachelines)[*]
A
This is not premature optimisation.
It is premature because the entire structure will be removed.
From: development-bounces+martin.smith=theqtcompany@qt-project.org
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of
Marc
41 matches
Mail list logo
