GVariant singletons

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GVariant singletons

Mikkel Kamstrup Erlandsen-4
Hi all,

In Unity, at least, we're pushing around quite a lot of GVariants, and
while it's not slow, I was wondering if we could make even faster. If
nothing, it would be a fun exercise :-)

The basic idea I have is stolen from Java's Boolean and  Integer classes
where they have singletons to help cut some corners in the garbage
collector and comparison methods. In Java that makes a big difference.
(for Integer they cache numbers up to 128 I believe)

I made a very simple benchmark to test something similar with GVariants,
which I have attached to this mail. Simulating that the TRUE GVariant is
a singleton I get numbers ala:

$ ./gvariant-singletons
CREATE 1000  : 0.000781s
DESTROY 1000 : 0.000430s
CREATE 1000  : 0.000042s (sngltn)
DESTROY 1000 : 0.000039s (sngltn)

Running the test numerous times I see speedups in the range of 5-20
times. Not mighty surprising - just verifies that ref() is faster than
new allocations, but still good to see it in raw numbers.

One could do something similar for low valued integers - I am mostly
thinking those that would be in the range of your average enum.

So I think this looks pretty interesting, and I'll probably look into it
over the next days; but any comments (or showstoppers?!) are most welcome.

And yes, yes, I know this is another slap in the face for the valgrind
camp. Sorry!

Cheers,
Mikkel

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

gvariant-singletons.c (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GVariant singletons

Simon McVittie-6
On Wed, 07 Dec 2011 at 20:06:32 +0100, Mikkel Kamstrup Erlandsen wrote:
> And yes, yes, I know this is another slap in the face for the
> valgrind camp. Sorry!

Commit a Valgrind suppressions file to GLib and all will be forgiven :-)

(But seriously: would people be interested in GLib having/installing a
suppressions file that silences many of the one-per-process
"deliberate leaks"? We have an incomplete one in telepathy-glib that would
be a good start.)

    S
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GVariant singletons

Bastien Nocera
On Thu, 2011-12-08 at 10:15 +0000, Simon McVittie wrote:

> On Wed, 07 Dec 2011 at 20:06:32 +0100, Mikkel Kamstrup Erlandsen wrote:
> > And yes, yes, I know this is another slap in the face for the
> > valgrind camp. Sorry!
>
> Commit a Valgrind suppressions file to GLib and all will be forgiven :-)
>
> (But seriously: would people be interested in GLib having/installing a
> suppressions file that silences many of the one-per-process
> "deliberate leaks"? We have an incomplete one in telepathy-glib that would
> be a good start.)

A way to disable the use of those singletons would also be good, as it
would mean a valgrind warning when you unref the last reference to the
singleton.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GVariant singletons

Tim-Philipp Müller
In reply to this post by Simon McVittie-6
On Thu, 2011-12-08 at 10:15 +0000, Simon McVittie wrote:

> (But seriously: would people be interested in GLib having/installing a
> suppressions file that silences many of the one-per-process
> "deliberate leaks"? We have an incomplete one in telepathy-glib that would
> be a good start.)

Yes, definitely. We also maintain GLib/GObject suppressions in GStreamer
for our unit tests, would be nice if we could just use an installed
suppression file instead.

Cheers
 -Tim



_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GVariant singletons

Andrew Cowie
On Thu, 2011-12-08 at 11:30 +0000, Tim-Philipp Müller wrote:

> Yes, definitely. We also maintain GLib/GObject suppressions in GStreamer
> for our unit tests, would be nice if we could just use an installed
> suppression file instead.

Came up on gtk-app-devel-list not to long ago;
http://mail.gnome.org/archives/gtk-app-devel-list/2011-November/msg00058.html 
I asked what the best location to install the suppression files would
be? Perhaps

        /usr/share/suppression/glib.sup
        /usr/share/suppression/gtk.sup
        /usr/share/suppression/pango.sup

Obviously if there's actually a convention as to where valgrind looks
for such files then we'd want to install them there...

AfC
Sydney


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GVariant singletons

Simon McVittie-6
On Fri, 09 Dec 2011 at 09:23:57 +1100, Andrew Cowie wrote:
> Came up on gtk-app-devel-list not to long ago;
> http://mail.gnome.org/archives/gtk-app-devel-list/2011-November/msg00058.html 
> I asked what the best location to install the suppression files would
> be? Perhaps
>
>         /usr/share/suppression/glib.sup
>         /usr/share/suppression/gtk.sup
>         /usr/share/suppression/pango.sup

/usr/lib/valgrind/*.supp (double p) is where it automatically looks.
Debian's Valgrind packaging already ships a few suppressions, mostly for
glibc.

For optimum parallel-installability of versions it may be best to use a
name corresponding to the SONAME of the library (e.g. libglib-2.0.so.0.supp,
libgtk-3.so.0.supp).

glib-2.0.supp, gtk-3.supp would also work if GLib, Gtk will (by policy)
never break ABI and become *.so.1.

I'll be on a train for a while today, so I'll see if I can distil something
generally-useful out of the suppressions in telepathy-glib and
gstreamer/common.

    S
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list