[regression] [performance] Mir spends 25% of its real-time in ~vector blocking the compositor thread

How did you run the test exactly (which server, how many clients etc)? Where compiler optimizations turned on?

Demo server. Five clients (egltriangle). Default optimization level (?)

> Default optimization level (?)

Default optimization level (i.e. not explicit -DCMAKE_BUILD_TYPE=... or no -Duse_debflags=true) is no optimization :/

Fair point. Though I personally believe performance-sensitive logic shouldn't be solely reliant on compiler optimizations being turned on.

Correction: Copying the vector is probably not the issue. C++11 should optimize that with move-construction. The issue is the vector instance is still constructed and destroyed on every call to composite(). We need to make vector reallocation less frequent than that.

After fixing bug 1349698, the figure for this one rises to 10% :/

With an optimized build (-Duse_debflags=true) the numbers I get for scene_elements allocation/deallocation are in the ~3% range. See http://people.ubuntu.com/~afrantzis/callgrind.out.8254.xz

Note that the largest part of that 3% is actually buffer management in BufferQueue, not related to vector (de)allocation.

Also note that without optimizations templates don't get inlined or otherwise optimized, causing significant overhead.

Verified the bottleneck is still occurring in the latest source (r1811):

1. Population of the vector: 3.24%
2. Destroying the vector: 4.75%
= 7.99%

This is CPU time spent not on actual rendering. Although there seems to be a lot of buffer/surface management going on underneath as shared_ptrs get released.

Finally got hold of a real-time based profiler that gives more accurate results (google-perftools).
This reveals our vector destruction (which indirectly includes sending buffer responses to all clients) takes 25% of Mir's time, slowing down and causing contention with the actual compositing.

Incomplete. I'm generating too much noise morphing this bug each time I think I understand it, so better to just treat it as an enhancement and submit a fix when it's ready.