How much does a g_object_set() cost?
I was wondering about this issue for PAF. I want to provide facilities to animate GObject properties, but is this something sensible? In the case of an interactive GUI, can we think of updating a hundred properties for each frame?
To answer these questions, I have written some code, that would do as many g_object_set()/g_object_get() as you want, and measure how much CPU time it takes. The code is available as a bzr branch at http://emont.org/property-tests/, look in the gobject directory (I have also written a similar code in python, and in "simple C" with nested structures).
The result of this, on my laptop (a Pentium M 1.86 GHz) is the following:
Here I ask for a million of sets, then a million of gets, then a million of couples get,set (to increment my float property by 0.1 at each iteration).
So, we can say that on my machine, a g_object_set() takes about 1.5 µs. Now, if we want to animate simultaneously a hundred properties, meaning that we want to update them all at each frame, we will spend 150µs just for g_object_set().
Let's consider we have a 60 Hz screen, that means we have a total time of 16.667 ms, or 16,667 µs, and that in that case, we will spend about 1% of our time updating properties; I want to say that's something that can be afforded in most cases. On modern embedded device, I guess we can expect the CPU to be up to 5 times slower, so in this case, that would be more like 5% of our time spent on updating GObject properties. That might be more of an issue, especially since CPU usage means energy consumption.
A question that remains open is Could g_object_set() be more efficient?
To be frank, I don't really know, but I have made a similar test with python:
I would tend to consider that the object system of python provides a similar set of functionality, but here, we're speaking of 0.3µs (about 5 times faster than GObject), so, yeah, I guess there is room for improvement in g_object_set(), but it is yet to be decided if it is worth it...
Yet, it is a certain thing that the price is cheap enough for animations on the desktop, and for that reason it makes sense to put GObject propertiy animation facilities in PAF, and to add GObject properties to Pigment or Clutter at some point, since it would tend to make the programming (and creation of language bindings) of these things much easier.
To answer these questions, I have written some code, that would do as many g_object_set()/g_object_get() as you want, and measure how much CPU time it takes. The code is available as a bzr branch at http://emont.org/property-tests/, look in the gobject directory (I have also written a similar code in python, and in "simple C" with nested structures).
The result of this, on my laptop (a Pentium M 1.86 GHz) is the following:
$ ./gobject/test 1000000
n=1000000
stress_set(): 1.440000
stress_get(): 0.480000
stress_get_set(): 1.940000
$
Here I ask for a million of sets, then a million of gets, then a million of couples get,set (to increment my float property by 0.1 at each iteration).
So, we can say that on my machine, a g_object_set() takes about 1.5 µs. Now, if we want to animate simultaneously a hundred properties, meaning that we want to update them all at each frame, we will spend 150µs just for g_object_set().
Let's consider we have a 60 Hz screen, that means we have a total time of 16.667 ms, or 16,667 µs, and that in that case, we will spend about 1% of our time updating properties; I want to say that's something that can be afforded in most cases. On modern embedded device, I guess we can expect the CPU to be up to 5 times slower, so in this case, that would be more like 5% of our time spent on updating GObject properties. That might be more of an issue, especially since CPU usage means energy consumption.
A question that remains open is Could g_object_set() be more efficient?
To be frank, I don't really know, but I have made a similar test with python:
$ python python/test.py 1000000
n= 1000000
stress_set(): 0.29
stress_get(): 0.14
stress_get_set(): 0.34
$
I would tend to consider that the object system of python provides a similar set of functionality, but here, we're speaking of 0.3µs (about 5 times faster than GObject), so, yeah, I guess there is room for improvement in g_object_set(), but it is yet to be decided if it is worth it...
Yet, it is a certain thing that the price is cheap enough for animations on the desktop, and for that reason it makes sense to put GObject propertiy animation facilities in PAF, and to add GObject properties to Pigment or Clutter at some point, since it would tend to make the programming (and creation of language bindings) of these things much easier.
No comment
Post a comment
All comments are held for moderation; basic HTML formatting accepted.