From 0968f903fe66f9bb8957b8d01e35f3743c74404b Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Tue, 4 Nov 2014 11:31:31 +0100 Subject: Brought old blog over --- ...these-arent-the-benchmarks-youre-looking-for.md | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 content/technical/these-arent-the-benchmarks-youre-looking-for.md (limited to 'content/technical/these-arent-the-benchmarks-youre-looking-for.md') diff --git a/content/technical/these-arent-the-benchmarks-youre-looking-for.md b/content/technical/these-arent-the-benchmarks-youre-looking-for.md new file mode 100644 index 0000000..1a81e8b --- /dev/null +++ b/content/technical/these-arent-the-benchmarks-youre-looking-for.md @@ -0,0 +1,27 @@ +Title: These aren't the benchmarks you're looking for +Date: 2010-10-19 +Tags: technical, gnome +Slug: this-arent-benchmarks-youre-looking-for + + +I was evaluating use of [GObject][] for small plentiful +short-lived objects in [libgck][]. I wanted to see how their performance +compared to custom reference counted structures. Turns out it's not as +bad as I imagined. + +The speed difference on my system, with a [simple test program][], ended +up being around a factor of eight. Most of that cost is due to +`pthread_mutex_lock` and `pthread_mutex_unlock`. + + :::text + $ ./test-gobject-speed + struct x 10000000 = 1.091700 + object x 10000000 = 8.578848 + +Note that I didn't use heavy weight stuff like properties or signals in +my benchmark. But I don't need those for this use case. + + + [GObject]: http://library.gnome.org/devel/gobject/unstable/ + [libgck]: http://stef.thewalter.net/2010/10/introducing-libgck-pkcs11-gobject.html + [simple test program]: http://thewalter.net/stef/misc/test-gobject-speed.c -- cgit v1.2.3