© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
> * We may see some tail latency improvements from using tcmalloc given the cases where we ended up in malloc seemed quite expensive (up to 65us).
Does it mean we need to override the new() operator for some classes? How does it work together with precompiled qt libraries?
> * ControlObject::set can cost 16us locking mutexes alone. Queued connections allocate memory too (which can also block). We really need to get COs out of the engine.
Yes! I have already thought about it what will be a good approach, that is performant, but not requires a change in our business logic.
On Idea was to implement a new CO Proxy type that has value buffer for pending changes from the engine and a chain pointer that allows to chain all touched COs.
During the callback set() writes the value buffer and puts the CO on top of the linked list.
After the engine call, a new threads works though the fifo list and updates the underlying CO accordingly.
Unfortunately I am not sure if this really improves the performance, because the work is still there and the fifo should be empty before we can continue with the next engine call.
If we assume that we protect these threads from each other by a single mutex, we use actually more CPU, but we benefit from multi core cpus.
Maybe we find a way to make the chain of Engine COs lock free
> * Why is SoundDeviceNetwork open when no shoutcast stream is enabled?
There is no strong reason for it. It requires some work to enable it on demand though.
> * Do we need to be calling gettimeofday from the engine thread?
Yes, that is the main reason for having SoundDeviceNetwork, it runs at the network synced gettimeofday clock.
By the way, there is a Pending PR, that allows to run the whole engine at this clock to remove sync artifacts from the broadcast stream: https:/