Performance Love Day

Why

Because GNOME can be faster.

There are many ways to improve performance, and some of them requires unique coding skills; but most of them just requires time, and will, to improve the current code-base. By optimizing bottle-necks, for instance. Or removing old code.

This GNOME Love Day focuses on doing this work: finding where those bottle-necks are, fixing known offenders, giving some love to GNOME in order to make it really fast.

When

• Sunday, October 30, 2005, from 14:00 UTC to 03:00 UTC

How

Join the #gnome-love IRC channel (GIMPnet), and ask for tasks, help or add your own ideas!

What

Here you'll find some tasks. Choose one, sign-up, and join the ride!

... And more to come

Who

Why, you of course!

Guidelines

First of all, optimizations should never be done without reason:

• (http://www.google.com/search?q=premature+optimization Google search on premature optimization)

So in case you're out to optimize something, make sure the benefits are really obvious, or to have hard profiling data available, showing the performance impacts and gains.

Optimizing runtime checks (g_assert(), g_return_if_fail(), ...)

Removing g_return_* macros from code can be an appropriate measure if the code in general and the checks in particular have been identified as performance bottlenecks in reproducable profiling scenarios.

However, in general, sprinkling additional checks over your code is a good idea. To build robust programs, it is preferrable to:

• Write type safe code whenever possible (avoid casts, care about the variable types you pick and their signedness, etc). This helps to catch errors upon compile time, before the first runtime ever.

• Add runtime checks to your code, such as g_assert() and g_return_if_fail(). Often, this leads to catch errors and failed contracts before a program shows actual misbehaviour and has to be debuged.

• Prefer g_return_if_fail() over g_assert(). Doing so may save the users work in faulty scenarios, because most often programs that spew g_return_if_fail() warnings can still save the work data, whereas triggering a g_assert() takes everything with it unrecoverably.

LuisMenina: I disagree with that, according to the GNOME Programming guidelines about assertions vs preconditions.

That being said, there are some cases where g_return_if_fail() checks can be beneficial to avoid if profiling data indicates that the check at hand is causing a noticable performance impact. One such case is signal handlers. Functions that are used as signal handlers only, don't need to check the object types passed in as often, because they are always called through the same mechanism, GSignal, which already asserts proper object types upon signal emissions.

Other cases where checks can be optimized are possible if:

• the callers always check for the parameters;

• the function is a proxy for another function of the platform library;

• a parameter has just being converted using a checked cast (e.g. GtkButton button = GTK_IS_BUTTON (user_data);)

Optionally, internal state checks could be substituted with g_assert(), in case of invariant data, or preferrably with g_return_if_fail() or a simple if (!condition) return. Keep in mind that robustness is important for production code, and while g_assert() helps to catch errors early, it also tends to make programs more fragile to unexpected cases, in constrast to silent checks or g_return_if_fail().

Profiling

while (gtk_events_pending ())
  gtk_main_iteration ();