Particles: replace a QSet<int> with a bit vector for group data.

The reusableIndexes represented a "free-list". Now the allocation
behavior in QQuickParticleGroupData::setSize was to grow by (large)
chunks. That means that as soon setSize was called, a (big) number of
hash entries was created, which are drained over time. This memory would
stay around (and probably unused) as long as the group was alive.

By using a bit vector, the amount of memory is much more compressed,
and finding an entry takes less time. The FreeList "caches" the next
free entry, because allocation and de-allocation behavior is that they
occur bunches: allocate a number of particles, use them, allocate the
same number.

Test case: samegame, 1 player, click 1 set of 3 stones, quit.
QQuickParticleSystem::emittersChanged(), before patch:
 - 21 instr. inclusive, 15M in QQuickParticleGroupData::setSize
 - 23,000 calls to QHashData::allocateNode
after:
 - 13M instr. inclusive, 7M in QQuickParticleGroupData::setSize
 - 0 calls to QHashData::allocateNode

Change-Id: If35ea5ed9b29129f210638f6f59275a24eb6afdc
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>

1 files changed, 10 insertions, 0 deletions

diff --git a/src/qml/jsruntime/qv4util_p.h b/src/qml/jsruntime/qv4util_p.h
index 132abd211e..59c12c5e46 100644
--- a/src/qml/jsruntime/qv4util_p.h
+++ b/src/qml/jsruntime/qv4util_p.h
@@ -102,6 +102,9 @@ public:
     void resize(int newSize)
     { bits.resize(newSize); }
 
+    void resize(int newSize, bool newValue)
+    { bits.resize(newSize, newValue); }
+
     void assign(int newSize, bool value)
     { bits.assign(newSize, value); }
 
@@ -159,6 +162,13 @@ public:
     void resize(int newSize)
     { bits.resize(newSize); }
 
+    void resize(int newSize, bool newValue)
+    {
+        int oldSize = bits.size();
+        bits.resize(newSize);
+        bits.fill(newValue, oldSize, bits.size());
+    }
+
     void assign(int newSize, bool value)
     {
         bits.resize(newSize);