• Immutable Page
  • Info
  • Attachments

Performance

There are a few ways which we can increase the performance of compiz - mostly by avoiding certain practices and doing things which are expensive.

Use references and const references wherever we are passing large data structures as arguments

It's very tempting to pass entire CompOption::Vectors or CompWindowLists as function arguments and even more easy to forget that you should really pass them as a const &. We need to go through the code and change this wherever possible. Generally speaking, you should never have to copy data structures this big.

Use threading when doing I/O

We need to look at every plugin that does I/O and use ptheads to handle that. Waiting for I/O is dangerous because it makes compiz stop rendering momentarily while your images or other things are being written or read

Specify masks in wrappable functions for even more granularity as to what circumstances plugins want to wrap functions under

It's great that we are now able to dynamically enable and disable wrapped functions for plugins when they are not in use. However, especially for functions like CompWindow::windowNotify and CompScreen::handleEvent, plugins might need to watch for particular "events" on windows (which happen to be specified in those functions) or might only need the function once or twice during a few hundred calls. In this case, we should add a new prototype ::##function##SetMask and ::##function##GetMask for each function. For example:

PluginScreen::PluginScreen (CompScreen *s) :
    ...
{
    FooInterface::setHandler (this, false); // disables all calls by default

    fScreen->functionSetMask (FOO_DO_THIS_MASK | FOO_DO_THAT_MASK); // only calls the function if the function is serving the purpose of FOO_DO_THIS or FOO_DO_THAT
    fScreen->functionSetMask (fScreen->functionGetMask () & ~(FOO_DO_THAT_MASK)); // now only function is called if it is for the purpose of FOO_DO_THIS
}

Avoid full-screen damages wherever possible

Requesting a redraw of the entire screen with CompositeScreen::damageScreen is expensive on the rasterization process and really shouldn't be used unless necessary. This is especially the case with per-window animations. In these cases, it is usually less expensive to calculate a bounding box for the animation and damage that instead rather than calling CompositeScreen::damageScreen. The only cases where this makes sense if where if you were to calculate the bounding box you must loop over a lot of variables and do a lot of calculation.

Development/Proposals/Performance (last edited 2010-11-02 12:41:15 by dsl-124-150-45-153)