On 2015-08-09 07:58, Kevin Kofler wrote:
Thiago Macieira wrote:
Please see the C++17 proposal of destructive moves instead.
It took 4 years for Qt to agree to require a limited subset of C++11, so,
realistically, C++17 features are not likely to end up used (everywhere, at
least) before
On 2015-08-09 21:58, Thiago Macieira wrote:
On Monday 10 August 2015 02:36:20 Kevin Kofler wrote:
realloc doesn't work if you are inserting or removing in the middle of a
vector.
Sure it does. It's required if you need to insert anywhere but don't have
enough space.
Now, if you're not
Thiago Macieira wrote:
On Sunday 09 August 2015 03:26:33 Kevin Kofler wrote:
Marc Mutz wrote:
On Friday 07 August 2015 19:41:07 Kuba Ober wrote:
How about making such traits explicitly necessary? People would then
have to learn about them. As a user, I wouldn't mind - the compiler
would
On Sunday 09 August 2015 03:26:33 Kevin Kofler wrote:
Marc Mutz wrote:
On Friday 07 August 2015 19:41:07 Kuba Ober wrote:
How about making such traits explicitly necessary? People would then have
to learn about them. As a user, I wouldn't mind - the compiler would pick
it all up for me.
On Sunday 09 August 2015 13:58:12 Kevin Kofler wrote:
Thiago Macieira wrote:
On Sunday 09 August 2015 03:26:33 Kevin Kofler wrote:
Marc Mutz wrote:
On Friday 07 August 2015 19:41:07 Kuba Ober wrote:
How about making such traits explicitly necessary? People would then
have to learn
Thiago Macieira wrote:
That is exactly what this proposal is not about. If you have a trait that
indicates your object type is trivially destrucible movable (a.k.a.
trivially relocatable), then we won't do memmove at all. We'll just do
realloc, period.
realloc doesn't work if you are
On Monday 10 August 2015 02:36:20 Kevin Kofler wrote:
Thiago Macieira wrote:
That is exactly what this proposal is not about. If you have a trait that
indicates your object type is trivially destrucible movable (a.k.a.
trivially relocatable), then we won't do memmove at all. We'll just do
On Friday 07 August 2015 19:41:07 Kuba Ober wrote:
How about making such traits explicitly necessary? People would then have
to learn about them. As a user, I wouldn't mind - the compiler would pick
it all up for me.
An option for Qt 6, but for Qt 5, it would be a source-incompatible change.
Marc Mutz wrote:
On Friday 07 August 2015 19:41:07 Kuba Ober wrote:
How about making such traits explicitly necessary? People would then have
to learn about them. As a user, I wouldn't mind - the compiler would pick
it all up for me.
An option for Qt 6, but for Qt 5, it would be a
On Tue, Jul 21, 2015 at 11:47 AM, Thiago Macieira thiago.macie...@intel.com
wrote:
On Tuesday 21 July 2015 10:19:59 Matthew Woehlke wrote:
On 2015-07-21 01:06, Thiago Macieira wrote:
Is it possible to have Qt type traits
on a type T such that QListT will always be QVector-like? Or would
That's an interesting observation. Would it be easy to add an api to QList
and QVector that would somehow keep track of the empty spots and use them
if available? In a `QList`, it would require only an extra pointer to the
first empty member slot, the slots would act as a singly-linked list.
Same
Giuseppe D'Angelo wrote:
Also nobody says that middle insertions of removals should be extra
cheap.
This is a very common operation for a random-access, ordered but not auto-
sorted, array/vector-type list. The array of pointers data structure is an
effective compromise to make this reasonably
On Monday 27 July 2015 21:44:32 Kevin Kofler wrote:
For bad types for QList, that O(1) is hiding two indirections. Only
one with QVector. That's a huge cost you're not talking about.
It's a factor 2, vs. a factor sizeof(T)/sizeof(T*) in the opposite
direction for the middle
Thiago Macieira wrote:
The total memory allocated for QList is always equal to or bigger than
QVector for the same size, regardless of T. So in addition to having the
same memory size, you access the data through one extra indirection.
I was talking about speed, not memory consumption.
The
On Monday 27 July 2015 00:27:18 Kevin Kofler wrote:
It doesn't switch the stuff it actually guarantees:
That sentence is perfectly correct.
But here's the catch: The docs guarantee _a certain implementation_, incl. the
switching. The problem is that the conditions under which the switch occurs
@qt-project.org on behalf of
Marc Mutz marc.m...@kdab.com
Sent: Monday, July 27, 2015 11:16 AM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Monday 27 July 2015 00:27:18 Kevin Kofler wrote:
It doesn't switch the stuff it actually
Thiago Macieira wrote:
Except if the type is larger than sizeof(void*), like QVariant is.
Or like QString and QByteArray will be in Qt 6.
Ewww, are you sure that that's a good idea?
Kevin Kofler
___
Development mailing list
PS: Oops:
I wrote:
* Inserting an element performs at most 1 heap allocation.
Before the hair-splitting begins, at most amortized 1, worst-case 2.
Kevin Kofler
___
Development mailing list
Development@qt-project.org
Marc Mutz wrote:
It makes perfect sense: A container should not subtle change memory layout
and switch guarantees in such a way that only experts know what it
actually does. That an array-list *might* be the most efficient container
for certain types and certain operations, no-one disputes.
On Monday 27 July 2015 00:19:16 Kevin Kofler wrote:
Thiago Macieira wrote:
Except if the type is larger than sizeof(void*), like QVariant is.
Or like QString and QByteArray will be in Qt 6.
Ewww, are you sure that that's a good idea?
Yes.
--
Thiago Macieira - thiago.macieira (AT)
On Mon, Jul 27, 2015 at 12:27 AM, Kevin Kofler kevin.kof...@chello.at wrote:
It doesn't switch the stuff it actually guarantees:
* Moving n elements in the list (for whatever reason) will only move
n*sizeof(void*) bytes (not n*sizeof(T), nor will it call any copy
constructors or
On Wednesday 22 July 2015 17:10:38 Giuseppe D'Angelo wrote:
Il 22/07/2015 16:52, Thiago Macieira ha scritto:
Allocators is a feature we've never supported and I don't see us
supporting.
I don't see a problem with the alignment. QArrayData is allocated with
alignment of
Il 22/07/2015 16:52, Thiago Macieira ha scritto:
Allocators is a feature we've never supported and I don't see us supporting.
I don't see a problem with the alignment. QArrayData is allocated with
alignment of min(alignof(QArrayData), alignof(T)), then we find the proper
alignment for T inside
By the way, is it possible to add custom allocators to the vector? As we have
to store reference counter (at least) with the data, wouldn't there be problems
with aligning of the memory?
Иван Комиссаров
21 июля 2015 г., в 21:44, Thiago Macieira thiago.macie...@intel.com
написал(а):
On
On Wednesday 22 July 2015 10:25:02 abba...@gmail.com wrote:
By the way, is it possible to add custom allocators to the vector? As we
have to store reference counter (at least) with the data, wouldn't there be
problems with aligning of the memory?
Allocators is a feature we've never supported
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly shared?
Yes, in large mode. In small string/array mode, they wouldn't share, of
course.
What about the conversion of std::vector to QVector and back. Do we get zero
copy
On Tuesday 21 July 2015 10:19:59 Matthew Woehlke wrote:
On 2015-07-21 01:06, Thiago Macieira wrote:
On Tuesday 21 July 2015 02:26:41 Kevin Kofler wrote:
For the implicitly shared data types, QList actually does NOT add another
layer of indirection (as documented: If T is itself a pointer
On Tuesday 21 July 2015 19:11:42 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly
On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly shared?
Yes, in large mode. In small string/array mode, they wouldn't share, of
course.
What about the
Thiago Macieira thiago.macie...@intel.com
On Tuesday 21 July 2015 16:14:18 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
Or like QString and QByteArray will be in Qt 6.
Are these still implicitly shared?
Yes, in large mode. In small string/array mode, they
On Tuesday 21 July 2015 17:11:42 Bubke Marco wrote:
Thiago Macieira thiago.macie...@intel.com
What about the conversion of std::vector to QVector and back. Do we get
zero copy conversion?
Can't be done.
What about wrapping QVector around std::vector.
Can't be done either if we want
From: development-bounces+marco.bubke=theqtcompany@qt-project.org
development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf of
Kevin Kofler kevin.kof...@chello.at
If you have large objects, and insert or remove items within the list,
QVector will have to move (or even
Op 21-7-2015 om 11:55 schreef Bubke Marco:
From: development-bounces+marco.bubke=theqtcompany@qt-project.org
development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf
of Kevin Kofler kevin.kof...@chello.at
If you have large objects, and insert or remove items within the
On 2015-07-21 01:06, Thiago Macieira wrote:
On Tuesday 21 July 2015 02:26:41 Kevin Kofler wrote:
For the implicitly shared data types, QList actually does NOT add another
layer of indirection (as documented: If T is itself a pointer type or a
basic type that is no larger than a pointer, or
Milian Wolff wrote:
Did you actually profile this? I don't see how a QVector could lead to
allocation hell, where QList would not be much worse.
If you have large objects, and insert or remove items within the list,
QVector will have to move (or even copydelete, if they're not movable)
large
Randall O'Reilly wrote:
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
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 that would fail the performance promises in the QList documentation.
QVector is NOT always more efficient.
Kevin Kofler
On Tuesday 21 July 2015 02:26:41 Kevin Kofler wrote:
For the implicitly shared data types, QList actually does NOT add another
layer of indirection (as documented: If T is itself a pointer type or a
basic type that is no larger than a pointer, or if T is one of Qt's shared
classes, then
On Tuesday 21 July 2015 02:57:34 Kevin Kofler wrote:
Marc Mutz wrote:
I maintain that because of that Janus-headedness of QList, QList should
be avoided at any cost for types for which it has not already been
established as public API, even if the alternatives, QVector or
QLinkedList,
On Monday 13 July 2015 13:26:03 Ulf Hermann wrote:
Mind that all this talk about QList being bad does *not* hold for
primitively movable types of exactly sizeof(void *). For example
QByteArray, which only consists of a single d-pointer. For those the
disadvantages of QList against QVector
Mind that all this talk about QList being bad does *not* hold for primitively
movable types of exactly sizeof(void *). For example QByteArray, which only
consists of a single d-pointer. For those the disadvantages of QList against
QVector don't manifest themselves, but the generated code is
On Monday 13 July 2015 16:04:44 Иван Комиссаров wrote:
AFAIK unused methods doesn't get instantiated, am i wrong?
You're thinking about normal instantiation as-you-go. I was talking about
explict instantiation (required when using extern templates (forbidding to
instantiate) in the header.
--
On Monday 13 July 2015 14:42:38 Milian Wolff wrote:
and `strip` the binaries afterwards. So it's still ~2KB worse off - any
chance for using `extern templates` or similar to reduce this code bloat?
Might work for QListQByteArray, but for most types, no. Explicitly
instantiating QList also
AFAIK unused methods doesn't get instantiated, am i wrong?
2015-07-13 18:09 GMT+03:00 Marc Mutz marc.m...@kdab.com:
On Monday 13 July 2015 14:42:38 Milian Wolff wrote:
and `strip` the binaries afterwards. So it's still ~2KB worse off - any
chance for using `extern templates` or similar to
El Sunday 12 July 2015, Marc Mutz escribió:
On Sunday 12 July 2015 13:11:54 Smith Martin wrote:
And yet you wrote a blog about it instead of submitting the info to us to
update the QList documentation. Currently, the QList page says this:
QListT, QLinkedListT, and QVectorT provide
On Sunday 12 July 2015 22:55:04 Alejandro Exojo wrote:
With respect to less code in your executable, note that in your blog
post
you said:
On the positive side, QList is a real memory saver when we talk about the
amount of code generated. That is because QList is but a thin wrapper
On Monday, July 13, 2015 12:45:00 AM Marc Mutz wrote:
On Sunday 12 July 2015 22:55:04 Alejandro Exojo wrote:
With respect to less code in your executable, note that in your blog
post
you said:
On the positive side, QList is a real memory saver when we talk about
the
amount of
On Monday 13 July 2015 00:45:00 Marc Mutz wrote:
Since that was written, I have seen QVector create less executable code
than QList. In theory, QList should expand to less memory, but inefficient
QLists, what with the heap allocations, probably uses more. Haven't
investigated much.
Not only
On Sunday 12 July 2015 13:11:54 Smith Martin wrote:
To me it looks like you're trying to argue about a very particular use of
QList. At that level of details, it has no business being in the docs.
And yet you wrote a blog about it instead of submitting the info to us to
update the QList
+martin.smith=theqtcompany@qt-project.org
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of
Marc Mutz marc.m...@kdab.com
Sent: Sunday, July 12, 2015 2:03 AM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Saturday
-bounces+martin.smith=theqtcompany@qt-project.org
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of
Marc Mutz marc.m...@kdab.com
Sent: Saturday, July 11, 2015 10:27 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use
On Saturday 11 July 2015 19:50:05 Smith Martin wrote:
Suppose (as in the use case that started this thread) that your
QList/QVector/QLinkedList will only have a small number of elements in it.
Almost always less than 5. Never more than about 8. Does this change the
analysis at all? In
On Saturday 11 July 2015 22:27:26 Marc Mutz wrote:
On Saturday 11 July 2015 19:25:20 Thiago Macieira wrote:
But Qt Creator was SO SLOW I noticed this when I tried to compile Qt
and moc was horribly slow too.
Does QList still use a linear growth strategy instead of a geometric one?
On Saturday, July 11, 2015 01:01:49 PM Thiago Macieira wrote:
On Saturday 11 July 2015 19:50:05 Smith Martin wrote:
Suppose (as in the use case that started this thread) that your
QList/QVector/QLinkedList will only have a small number of elements in it.
Almost always less than 5. Never
On Saturday 11 July 2015 21:50:05 Smith Martin wrote:
Suppose (as in the use case that started this thread) that your
QList/QVector/QLinkedList will only have a small number of elements in it.
Almost always less than 5. Never more than about 8. Does this change the
analysis at all? In
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
UP: Don't use QList, use Q_DECLARE_TYPEINFO
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
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
Subject: Re: [Development] HEADS UP: Don't use QList, use
Q_DECLARE_TYPEINFO
[snip]
(*) 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
, July 10, 2015 12:05 PM
To: Smith Martin; development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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
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.
-project.org
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of
Giuseppe D'Angelo giuseppe.dang...@kdab.com
Sent: Friday, July 10, 2015 1:26 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
Il 10/07/2015 13:21, Smith
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
Wolff milian.wo...@kdab.com
Sent: Friday, July 10, 2015 2:04 PM
To: development@qt-project.org
Cc: Smith Martin; Giuseppe D'Angelo
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Friday 10 July 2015 11:35:34 Smith Martin wrote:
1) you put pressure on the memory
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
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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
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.
=theqtcompany@qt-project.org
development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of
Marc Mutz marc.m...@kdab.com
Sent: Friday, July 10, 2015 1:25 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Friday 10 July 2015
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
: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Friday 10 July 2015 12:32:45 Smith Martin wrote:
Maybe it's just me, but I'm still not understanding your explanation, and I
don't think you are answering my question:
I think the impedance mismatch here is that you use list to mean
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
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
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
; Giuseppe D'Angelo
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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
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
Mutz marc.m...@kdab.com
Sent: Friday, July 10, 2015 5:32 PM
To: development@qt-project.org
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
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
93 matches
Mail list logo
