Performance tip QML other: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
[[Category:Developing_with_Qt::Qt Quick]]<br />[[Category:Developing_with_Qt::Performance Tips]]
[[Category:Developing_with_Qt::Qt Quick]]
[[Category:Developing_with_Qt::Performance Tips]]


[toc align_right=&quot;yes&amp;quot; depth=&quot;3&amp;quot;]
[toc align_right="yes" depth="3"]


== Fixed length lists with Flickable+Column+Repeater ==
== Fixed length lists with Flickable+Column+Repeater ==
Line 48: Line 49:
* For example, =Image= and =BorderImage= have a source, which is of type =url=. Conversion is needed if image source's property is defined as =string=, it should rather be =property url=.
* For example, =Image= and =BorderImage= have a source, which is of type =url=. Conversion is needed if image source's property is defined as =string=, it should rather be =property url=.


* Wrong way:<br /><code><br />property string messageAvatar: &quot;&quot;<br /></code>
* Wrong way:
<code>
property string messageAvatar: ""
</code>


* Right way:<br /><code><br />property url messageAvatar: &quot;&quot;<br /></code>
* Right way:
<code>
property url messageAvatar: ""
</code>


== Anchors and memory consumption ==
== Anchors and memory consumption ==
Line 60: Line 67:




* The normal way:<br /><code><br />Item {<br /> width: 800<br /> height: 400<br /> Button {<br /> id: button;<br /> objectName: &quot;Button&amp;quot;;<br /> anchors.top: parent.top<br /> anchors.left: parent.left<br /> anchors.right: parent.right<br /> text: &quot;Press me&amp;quot;;<br /> }<br />}<br /></code>
* The normal way:
<code>
Item {
width: 800
height: 400
Button {
id: button;
objectName: "Button";
anchors.top: parent.top
anchors.left: parent.left
anchors.right: parent.right
text: "Press me";
}
}
</code>


* This way consumes slightly less memory:<br /><code><br />Item {<br /> width: 800<br /> height: 400<br /> Button {<br /> id: button;<br /> objectName: &quot;Button&amp;quot;;<br /> anchors { top: parent.top; left: parent.left; right: parent.right }<br /> text: &quot;Press me&amp;quot;;<br /> }<br />}<br /></code>
* This way consumes slightly less memory:
<code>
Item {
width: 800
height: 400
Button {
id: button;
objectName: "Button";
anchors { top: parent.top; left: parent.left; right: parent.right }
text: "Press me";
}
}
</code>


== Beware of string operations ==
== Beware of string operations ==


* Multiple uses of the '''' operator usually means multiple memory allocations<br />* Use [[Image:StringBuilder for more efficient strings. |StringBuilder for more efficient strings. ]]QStringBuilder uses expression templates and reimplements the '' operator so that when you use '' for string concatenation instead of '''', multiple substring concatenations will be postponed until the final result is about to be assigned to a QString. At this point, the amount of memory required for the final result is known. The memory allocator is then called once to get the required space, and the substrings are copied into it one by one.
* Multiple uses of the '''' operator usually means multiple memory allocations
* Use [[Image:StringBuilder for more efficient strings. |StringBuilder for more efficient strings. ]]QStringBuilder uses expression templates and reimplements the '' operator so that when you use '' for string concatenation instead of '''', multiple substring concatenations will be postponed until the final result is about to be assigned to a QString. At this point, the amount of memory required for the final result is known. The memory allocator is then called once to get the required space, and the substrings are copied into it one by one.
* Define: QT_USE_FAST_CONCATENATION, QT_USE_FAST_OPERATOR_PLUS
* Define: QT_USE_FAST_CONCATENATION, QT_USE_FAST_OPERATOR_PLUS

Revision as of 10:21, 25 February 2015


[toc align_right="yes" depth="3"]

Fixed length lists with Flickable+Column+Repeater

If you have a simple list with fixed length, you could try to optimize performance using Flickable+Column+Repeater instead of QML ListView. This way list creation would be slower, but list scrolling smoother.


Animate as small area of the screen as possible in transition animations

If you need to move 3 elements in a second try moving each at a time in 300ms. The system works so that it calculates the bounds of items that need repainting and paints everything inside those bounds. This can be really bad two little things are animating in opposite corners.


Avoid complex clipping

You should enable clipping only when you really need it. The default clip value is false.


Does it help performance if you strip off comments or white space from QML files?

Not really. The files are reprocessed into a binary in-memory representation at startup, so by runtime there should be no performance difference. You might be lucky and get 0.5% improvement, and then only on start-up (where QML parsing is done), nowhere else.


Avoid unnecessary conversion

QML performs a type conversion if the given value for a property does not match with the type specified for the property. This conversion consumes additional memory.


  • For example, =Image= and =BorderImage= have a source, which is of type =url=. Conversion is needed if image source's property is defined as =string=, it should rather be =property url=.
  • Wrong way:
property string messageAvatar: ""
  • Right way:
property url messageAvatar: ""

Anchors and memory consumption

Anchoring can be done in two ways:


  • The normal way:
Item {
 width: 800
 height: 400
 Button {
 id: button;
 objectName: "Button";
 anchors.top: parent.top
 anchors.left: parent.left
 anchors.right: parent.right
 text: "Press me";
 }
}
  • This way consumes slightly less memory:
Item {
 width: 800
 height: 400
 Button {
 id: button;
 objectName: "Button";
 anchors { top: parent.top; left: parent.left; right: parent.right }
 text: "Press me";
 }
}

Beware of string operations

  • Multiple uses of the ' operator usually means multiple memory allocations
  • Use StringBuilder for more efficient strings.QStringBuilder uses expression templates and reimplements the operator so that when you use for string concatenation instead of ', multiple substring concatenations will be postponed until the final result is about to be assigned to a QString. At this point, the amount of memory required for the final result is known. The memory allocator is then called once to get the required space, and the substrings are copied into it one by one.
  • Define: QT_USE_FAST_CONCATENATION, QT_USE_FAST_OPERATOR_PLUS