On Fri, Sep 25, 2009 at 1:16 AM, A. Walton <awalton gnome org> wrote: > Just have a small question on the subject: has anyone performed any > library or application benchmarks to see how much this means in the > real world and not just for the threaded microbenchmarks that you > wrote? The non-threaded speedups are pretty impressive on their own, > but it'd be nice to see what we could expect from e.g. GStreamer with > these changes applied. > The motivations for the patches have in all cases been real world problems, though I never explicitly benchmarked the effects afterwards, as I was happy just looking at my microbenchmarks. The work on lockless O(1) interface lookups was motivated by trying to sort a huge treeview and getting a huge overhead from it. I just tested my simple liststore script again (attached here), and sorting the numbers column on that liststore is roughly 25% faster now. So I'd expect you to see these improvements in multithreaded apps that sort huge treeviews: file chooser and nautilus with lots of files, probably evolution in huge dirs. Speeding up g_type_class_ref() was not motivated by code that's already out in the wild, but by the desire to make ever smaller objects into real objects, that is currently not feasible due to this overhead. Examples here are an mpegps (mpegts?) parser the GStreamer guys had been working on, that was having 70% overhead just creating lots of small GstBuffers, Philip Van Hoof's work on Iterable interfaces or Vala automatically making a GObject out of Vala classes. So no real code I can point you at, but definitely a huge demand. The big problem with "show me real-life benchmarks" type questions is that developers usually work around visible limitations in lower layers, so you cannot see any immediate results. Instead, developers can - if they realize the limitations are gone - get rid of their workarounds or use features that previously just didn't work. And then people can get rid of APIs like for example g_type_class_peek_static() (for g_type_class_ref()), ETable (for GtkTreeView) or libgstvideo (for Cairo). Benjamin
Attachment:
liststore.py
Description: Binary data