Re: [Development] QML instantiation performance
Hi.
on windows that is even worse as the
qtdeclarative/tests/benchmarks/qml/librarymetrics_performance benchmark is
crashing in many testcases. 5.2.1 runs some more cases than 5.3.2 and 5.4
beta.
the test cases which crash in 5.3.2 and 5.4 beta are:
//QTest::newRow("039) listView - with anchors and list model content with
delegate") << testFileUrl("data/listview.3.qml");
// QTest::newRow("046) image - with content, async") <<
testFileUrl("data/image.4.qml");
// QTest::newRow("053) repeater - row - repeat simple rectangle") <<
testFileUrl("data/repeater.1.qml");
// QTest::newRow("054) repeater - column - repeat simple rectangle") <<
testFileUrl("data/repeater.2.qml");
// QTest::newRow("058) positioning - anchored positioning") <<
testFileUrl("data/anchoredpositioning.qml");
// QTest::newRow("059) positioning - anchored (with grid) positioning") <<
testFileUrl("data/anchorwithgridpositioning.qml");
// QTest::newRow("061) positioning - anchored (with binding) positioning") <<
testFileUrl("data/anchorwithbindingpositioning.qml");
// QTest::newRow("03) positioning - anchored positioning") <<
testFileUrl("data/anchoredpositioning.2.qml");
// QTest::newRow("04) positioning - anchored (with grid) positioning") <<
testFileUrl("data/anchorwithgridpositioning.2.qml");
// QTest::newRow("06) positioning - anchored (with binding) positioning") <<
testFileUrl("data/anchorwithbindingpositioning.2.qml");
// QTest::newRow("07) positioning - binding (with grid) positioning") <<
testFileUrl("data/bindingwithgridpositioning.2.qml");
I tried to let it run with 5.1 on windows but i am getting lots of weird
warnings i dont understand:
Config: Using QtTest library 5.1.0, Qt 5.1.0
PASS : tst_librarymetrics_performance::initTestCase()
QWARN : tst_librarymetrics_performance::compilation(001) item - empty) ERROR:
(file:///data/item.1.qml:3:1: Item is not a type
Item {
^)
where item.1.qml is just
importQtQuick2.0
Item{
}
i also get this for other types in the other tests. Furthermore i get:
QWARN : tst_librarymetrics_performance::instantiation_cached(007) item -
uninitialised Item prop) QQmlComponent: Component is not ready
a lot.
When looking at the all the perf numbers for 5.2.1 and 5.3.2, i can see that a
lot are slower in 5.3.2 but only a few faster . Comparing 5.3.2 with 5.4 some
are slower some are faster.
as for 5.1.0 , getting most of the time errors i dont count the result as
reliable.
As the positioner tests work for all, so here are these results
Qt 5.1.0 has
PASS : tst_librarymetrics_performance::instantiation(056) positioning - no
positioning)
RESULT : tst_librarymetrics_performance::instantiation():"056) positioning - no
positioning":
2,936,250 nsecs
RESULT : tst_librarymetrics_performance::instantiation():"056) positioning - no
positioning":
2,936,250 nsecs
PASS : tst_librarymetrics_performance::instantiation(057) positioning -
absolute positioning)
RESULT : tst_librarymetrics_performance::instantiation():"057) positioning -
absolute positioning":
3,101,814 nsecs
RESULT : tst_librarymetrics_performance::instantiation():"057) positioning -
absolute positioning":
3,101,814 nsecs
PASS : tst_librarymetrics_performance::instantiation(060) positioning -
binding positioning)
RESULT : tst_librarymetrics_performance::instantiation():"060) positioning -
binding positioning":
3,054,007 nsecs
RESULT : tst_librarymetrics_performance::instantiation():"060) positioning -
binding positioning":
3,054,007 nsecs
PASS : tst_librarymetrics_performance::instantiation(062) positioning -
binding (with grid) positioning)
RESULT : tst_librarymetrics_performance::instantiation():"062) positioning -
binding (with grid) positioning":
2,984,185 nsecs
RESULT : tst_librarymetrics_performance::instantiation():"062) positioning -
binding (with grid) positioning":
2,984,185 nsecs
PASS : tst_librarymetrics_performance::positioners(01) positioning - no
positioning)
RESULT : tst_librarymetrics_performance::positioners():"01) positioning - no
positioning":
2,958,458 nsecs
RESULT : tst_librarymetrics_performance::positioners():"01) positioning - no
positioning":
2,958,458 nsecs
PASS : tst_librarymetrics_performance::positioners(02) positioning - absolute
positioning)
RESULT : tst_librarymetrics_performance::positioners():"02) positioning -
absolute positioning":
3,096,950 nsecs
RESULT : tst_librarymetrics_performance::positioners():"02) positioning -
absolute positioning":
3,096,950 nsecs
PASS : tst_librarymetrics_performance::positioners(05) positioning - binding
positioning)
RESULT : tst_librarymetrics_performance::positioners():"05) positioning -
binding positioning":
3,085,942 nsecs
Qt 5.2.1 has much slower results:
PASS : tst_librarymetrics_performance::instantiation(056) positioning - no
positioning)
RESULT : tst_librarymetrics_performance::instantiation():"056) positioning
Re: [Development] changing Q_GADGET
On 28/11/2014 16:13, Gunnar Roth wrote: > Hi Simon > >> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event >> that somebody >> a) produces a DLL and cares about binary compatibility > > Why do you think that is unlikely? > > Actually right now i depend on that. I get stuff build against qt 5.2.1 dlls > and use that stuff and my stuff using at 5.3.2 by exchanginng thge qt dlls > with my 5.3.2 dlls , so i rely on binary compatibility. What’s unlikely is that you get all a), b) and c) : a) produces a DLL and cares about binary compatibility b) exposes bare structures c) relies on Q_GADGET turning access permission levels to private I guess most people don’t do c). Actually, any sane person would not like a macro to change the private / public context as a side effect, and the fact that Q_OBJECT does it (because it just can’t do otherwise) should more be considered a bug / lack in C++ than anything else, certainly not a feature to rely on. However, i may be missing something but Q_GADGET needs also to explicitely change the private / public context to introduce public members. So, the initial proposal to not changing that context would require Q_GADGET to be in a public context. I guess that one would break a lot of code. Regards, Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
Hi Simon >2) On paper it breaks binary compatibility with MSVC, in the unlikely event >that somebody >a) produces a DLL and cares about binary compatibility Why do you think that is unlikely? Actually right now i depend on that. I get stuff build against qt 5.2.1 dlls and use that stuff and my stuff using at 5.3.2 by exchanginng thge qt dlls with my 5.3.2 dlls , so i rely on binary compatibility. Regards, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
On Friday 28. November 2014 12.41.47 Olivier Goffart wrote:
> On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
> > Hi,
> >
> > Monsieur Goffart did awesome work in the dev branch on allowing structures
> > with Q_GADGET to have properties and invokable methods. This brings the
> > macro to a much wider audience and I'd like to use this opportunity to
> > propose a slight change to it that may be controversial:
> >
> > The macros Q_OBJECT and Q_GADGET both - towards the end of their
> > definition
> > - change the member access permission level to "private". It's always been
> > that way.
> >
> > I'd like to propose changing Q_GADGET to not change the access permission
> > level, so that you can write
> >
> > struct MyStructure
> > {
> >
> > Q_PROPERTY(int x MEMBER x)
> > Q_GADGET
> >
> > int x;
> >
> > }
> >
> >
> > I feel that Q_GADGET has its primary use with structures and the default
> > access level for those is public. I find it awkward that you currently
> > have
> > to write:
> >
> > structure MyStructure
> > {
> >
> > Q_PROPERTY(int x MEMBER X)
> > Q_GADGET
> >
> > public:
> > int x;
> >
> > }
> >
> >
> > The proposed change would have two effects:
> >
> > 1) It makes any existing code that _relies_ on Q_GADGET turning to private
> > suddenly expose members in structures.
> >
> > 2) On paper it breaks binary compatibility with MSVC, in the unlikely
> > event
> > that somebody
> >
> > a) produces a DLL and cares about binary compatibility
> > b) exposes bare structures
> > c) relies on Q_GADGET turning access permission levels to private
> >
> > I feel that the effects are negligible compared to the benefit of a better
> > API.
> >
> > What do you think?
>
> I have several times been bitten by the same problem when i used Q_OBJECT in
> a struct.
> But when I weight the pro and the cons, i'm not sure if it's a good idea.
>
> Pros:
> + Save one line when declaring a Q_GADGET in a struct
>
> Cons:
> - The change may change some member (data or function) from private to
> public - Is inconsistent with Q_OBJECT (and both are usually used in class)
> - Something that is incorrectly set as private will result in compilation
> errors that will be easily spotted and fixed. Something inadvertently left
> public will stay unnoticed until it's too late to change it.
>
>
> Notice that in our code we recommend to always use class and almost never
> struct. All the Q_GADGET today are class.
Hmm, that's a good point. I may be living in an over-simplified world where I
use struct more often than others. (in my dream world class also defaults to
public). The reality is probably that both macros are perhaps more likely to
be used in the class context and that consistency between the macros might
outweigh the inconsistency to struct.
Simon
> An alternative to save that line might also be to put the Q_GADGET macro at
> the end of the struct.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
On Friday 28. November 2014 13.36.56 Al-Khanji Louai wrote: > Out of the box, C++ makes class member declarations private. I quite > strongly feel that changing that behavior in a macro is not what the user > expects. So for me at least the "better API" box is not being checked here > - I quite regularly declare private variables under Q_OBJECT and have done > so with Q_GADGET as well. Well, that is exactly the motivation. Class members are private by default, struct members are public by default. Q_GADGET is changing that for no good reason :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
Out of the box, C++ makes class member declarations private. I quite strongly
feel that changing that behavior in a macro is not what the user expects. So
for me at least the "better API" box is not being checked here - I quite
regularly declare private variables under Q_OBJECT and have done so with
Q_GADGET as well.
-- Louai
> Hi,
>
> Monsieur Goffart did awesome work in the dev branch on allowing
> structures with
> Q_GADGET to have properties and invokable methods. This brings the macro
> to a
> much wider audience and I'd like to use this opportunity to propose a slight
> change to it that may be controversial:
>
> The macros Q_OBJECT and Q_GADGET both - towards the end of their
> definition -
> change the member access permission level to "private". It's always been
> that
> way.
>
> I'd like to propose changing Q_GADGET to not change the access permission
> level, so that you can write
>
> struct MyStructure
> {
> Q_PROPERTY(int x MEMBER x)
> Q_GADGET
>
> int x;
> }
>
>
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently have to
> write:
>
> structure MyStructure
> {
> Q_PROPERTY(int x MEMBER X)
> Q_GADGET
> public:
> int x;
> }
>
>
> The proposed change would have two effects:
>
> 1) It makes any existing code that _relies_ on Q_GADGET turning to private
> suddenly expose members in structures.
>
> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event
> that somebody
> a) produces a DLL and cares about binary compatibility
> b) exposes bare structures
> c) relies on Q_GADGET turning access permission levels to private
>
>
> I feel that the effects are negligible compared to the benefit of a better
> API.
>
> What do you think?
>
>
> Simon
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
On Friday 28 November 2014 12:41:47 Olivier Goffart wrote:
> On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
> > Hi,
> >
> > Monsieur Goffart did awesome work in the dev branch on allowing structures
> > with Q_GADGET to have properties and invokable methods. This brings the
> > macro to a much wider audience and I'd like to use this opportunity to
> > propose a slight change to it that may be controversial:
> >
> > The macros Q_OBJECT and Q_GADGET both - towards the end of their
> > definition
> > - change the member access permission level to "private". It's always been
> > that way.
> >
> > I'd like to propose changing Q_GADGET to not change the access permission
> > level, so that you can write
> >
> > struct MyStructure
> > {
> >
> > Q_PROPERTY(int x MEMBER x)
> > Q_GADGET
> >
> > int x;
> >
> > }
> >
> >
> > I feel that Q_GADGET has its primary use with structures and the default
> > access level for those is public. I find it awkward that you currently
> > have
> > to write:
> >
> > structure MyStructure
> > {
> >
> > Q_PROPERTY(int x MEMBER X)
> > Q_GADGET
> >
> > public:
> > int x;
> >
> > }
> >
> >
> > The proposed change would have two effects:
> >
> > 1) It makes any existing code that _relies_ on Q_GADGET turning to private
> > suddenly expose members in structures.
> >
> > 2) On paper it breaks binary compatibility with MSVC, in the unlikely
> > event
> > that somebody
> >
> > a) produces a DLL and cares about binary compatibility
> > b) exposes bare structures
> > c) relies on Q_GADGET turning access permission levels to private
> >
> > I feel that the effects are negligible compared to the benefit of a better
> > API.
> >
> > What do you think?
>
> I have several times been bitten by the same problem when i used Q_OBJECT in
> a struct.
> But when I weight the pro and the cons, i'm not sure if it's a good idea.
>
> Pros:
> + Save one line when declaring a Q_GADGET in a struct
>
> Cons:
> - The change may change some member (data or function) from private to
> public - Is inconsistent with Q_OBJECT (and both are usually used in class)
> - Something that is incorrectly set as private will result in compilation
> errors that will be easily spotted and fixed. Something inadvertently left
> public will stay unnoticed until it's too late to change it.
>
> Notice that in our code we recommend to always use class and almost never
> struct. All the Q_GADGET today are class.
>
> An alternative to save that line might also be to put the Q_GADGET macro at
> the end of the struct.
Why don't you just introduce a new macro?
Bye
--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
> Hi,
>
> Monsieur Goffart did awesome work in the dev branch on allowing structures
> with Q_GADGET to have properties and invokable methods. This brings the
> macro to a much wider audience and I'd like to use this opportunity to
> propose a slight change to it that may be controversial:
>
> The macros Q_OBJECT and Q_GADGET both - towards the end of their definition
> - change the member access permission level to "private". It's always been
> that way.
>
> I'd like to propose changing Q_GADGET to not change the access permission
> level, so that you can write
>
> struct MyStructure
> {
> Q_PROPERTY(int x MEMBER x)
> Q_GADGET
>
> int x;
> }
>
>
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently have
> to write:
>
> structure MyStructure
> {
> Q_PROPERTY(int x MEMBER X)
> Q_GADGET
> public:
> int x;
> }
>
>
> The proposed change would have two effects:
>
> 1) It makes any existing code that _relies_ on Q_GADGET turning to private
> suddenly expose members in structures.
>
> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event
> that somebody
> a) produces a DLL and cares about binary compatibility
> b) exposes bare structures
> c) relies on Q_GADGET turning access permission levels to private
>
>
> I feel that the effects are negligible compared to the benefit of a better
> API.
>
> What do you think?
I have several times been bitten by the same problem when i used Q_OBJECT in a
struct.
But when I weight the pro and the cons, i'm not sure if it's a good idea.
Pros:
+ Save one line when declaring a Q_GADGET in a struct
Cons:
- The change may change some member (data or function) from private to public
- Is inconsistent with Q_OBJECT (and both are usually used in class)
- Something that is incorrectly set as private will result in compilation
errors that will be easily spotted and fixed. Something inadvertently left
public will stay unnoticed until it's too late to change it.
Notice that in our code we recommend to always use class and almost never
struct. All the Q_GADGET today are class.
An alternative to save that line might also be to put the Q_GADGET macro at
the end of the struct.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
On 28 Nov 2014, at 12:19, Simon Hausmann
wrote:
> Hi,
>
> Monsieur Goffart did awesome work in the dev branch on allowing structures
> with
> Q_GADGET to have properties and invokable methods. This brings the macro to a
> much wider audience and I'd like to use this opportunity to propose a slight
> change to it that may be controversial:
>
> The macros Q_OBJECT and Q_GADGET both - towards the end of their definition -
> change the member access permission level to "private". It's always been that
> way.
>
> I'd like to propose changing Q_GADGET to not change the access permission
> level, so that you can write
>
> struct MyStructure
> {
>Q_PROPERTY(int x MEMBER x)
>Q_GADGET
>
>int x;
> }
>
>
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently have
> to
> write:
>
> structure MyStructure
> {
>Q_PROPERTY(int x MEMBER X)
>Q_GADGET
> public:
>int x;
> }
>
>
> The proposed change would have two effects:
>
> 1) It makes any existing code that _relies_ on Q_GADGET turning to private
> suddenly expose members in structures.
>
> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event
> that somebody
>a) produces a DLL and cares about binary compatibility
>b) exposes bare structures
>c) relies on Q_GADGET turning access permission levels to private
>
>
> I feel that the effects are negligible compared to the benefit of a better
> API.
Is it really only about the desire to avoid writing “public:” above the public
data? But on the other hand, if you wanted the data to be private you would
probably have declared it that way, in either a class or a struct; so the
convenience of having either macro make the default private is limited, right?
What are the right reasons to use structs instead of classes? Is it only for
the reason that members are public by default?
Why is Q_GADGET mainly used for structs and not classes? Now that it has more
features, maybe it could get used for some classes too.
Should we have public documentation for Q_GADGET?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
> -Original Message-
> From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
> [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org]
> On Behalf Of Simon Hausmann
> Sent: Friday, 28 November 2014 12:20 PM
> To: development@qt-project.org
> Subject: [Development] changing Q_GADGET
>
> Hi,
>
> Monsieur Goffart did awesome work in the dev branch on allowing
> structures with
> Q_GADGET to have properties and invokable methods. This brings the macro
> to a
> much wider audience and I'd like to use this opportunity to propose a
> slight
> change to it that may be controversial:
>
> The macros Q_OBJECT and Q_GADGET both - towards the end of their
> definition -
> change the member access permission level to "private". It's always been
> that
> way.
>
> I'd like to propose changing Q_GADGET to not change the access
> permission
> level, so that you can write
>
> struct MyStructure
> {
> Q_PROPERTY(int x MEMBER x)
> Q_GADGET
>
> int x;
> }
>
>
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently
> have to
> write:
>
> structure MyStructure
> {
> Q_PROPERTY(int x MEMBER X)
> Q_GADGET
> public:
> int x;
> }
>
>
> The proposed change would have two effects:
>
> 1) It makes any existing code that _relies_ on Q_GADGET turning to
> private
> suddenly expose members in structures.
>
> 2) On paper it breaks binary compatibility with MSVC, in the unlikely
> event
> that somebody
> a) produces a DLL and cares about binary compatibility
> b) exposes bare structures
> c) relies on Q_GADGET turning access permission levels to private
>
>
> I feel that the effects are negligible compared to the benefit of a
> better API.
>
> What do you think?
>
>
> Simon
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
This sounds quite reasonable to me. I wasn't even aware of this behaviour, and
would be quite worried if people were using these macros as access modifiers.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] changing Q_GADGET
Hi,
Monsieur Goffart did awesome work in the dev branch on allowing structures with
Q_GADGET to have properties and invokable methods. This brings the macro to a
much wider audience and I'd like to use this opportunity to propose a slight
change to it that may be controversial:
The macros Q_OBJECT and Q_GADGET both - towards the end of their definition -
change the member access permission level to "private". It's always been that
way.
I'd like to propose changing Q_GADGET to not change the access permission
level, so that you can write
struct MyStructure
{
Q_PROPERTY(int x MEMBER x)
Q_GADGET
int x;
}
I feel that Q_GADGET has its primary use with structures and the default
access level for those is public. I find it awkward that you currently have to
write:
structure MyStructure
{
Q_PROPERTY(int x MEMBER X)
Q_GADGET
public:
int x;
}
The proposed change would have two effects:
1) It makes any existing code that _relies_ on Q_GADGET turning to private
suddenly expose members in structures.
2) On paper it breaks binary compatibility with MSVC, in the unlikely event
that somebody
a) produces a DLL and cares about binary compatibility
b) exposes bare structures
c) relies on Q_GADGET turning access permission levels to private
I feel that the effects are negligible compared to the benefit of a better API.
What do you think?
Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
