Artificial performance limitation

[Daniel van Vugt]

Pretty pictures of a stuttering server attached.

Notice the CompositingFunctor where ~vector destruction is consuming 30% 
of the time, due to ~TemporaryCompositorBuffer taking 27% of the time.

I think we need to move the final buffer release/response logic out of 
the compositor thread one way or another, because blocking the 
compositor thread is a very visible problem.


On 03/11/14 08:36, Daniel van Vugt wrote:
> This bug and its sister bug are driving me crazy:
> https://bugs.launchpad.net/mir/+bug/1388490
> https://bugs.launchpad.net/mir/+bug/1377872
>
> I can see in both cases that the frame rate ceiling is arbitrary and
> temporary. It has nothing at all to do with the power of the host. And
> the workaround that fixes the problem in both cases is a bit crazy.
>
> I've so far investigated theories around:
>    * buffer lifetimes
>    * Mesa/intel GL batching bugs
>    * lock contention (locks held too long)
>    * power management modes
>    * Mir socket/protocol bottlenecks
>
> All the theories have some merit but I am not making progress. If you
> are (un)lucky enough to be able to reproduce either bug then please join
> in. More data points are required.
>
> - Daniel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mir-demo-shell-google-profile.svg.gz
Type: application/gzip
Size: 21274 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20141113/28d5f6a0/attachment-0001.bin>