After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703582 - gobject are slow to create
gobject are slow to create
Product: glib
Classification: Platform
Component: gobject
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
Depends on:
Reported: 2013-07-04 01:18 UTC by Derek Dai
Modified: 2018-05-24 15:28 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Derek Dai 2013-07-04 01:18:21 UTC
gobject is a great idea and I love it. But the object creation time is long. I wrote a small program to benchmark variety kinds of memory/object allocating performance. You can download from here:
Comment 1 Emmanuele Bassi (:ebassi) 2013-07-04 11:31:03 UTC
this is not really a bug report: there are no actionable items, here.

can you update/enhance the performance testing in the GObject tree instead? it would help us review your code properly, and it would help us putting numbers in context.
Comment 2 Derek Dai 2013-07-05 15:22:38 UTC
Here is the test results. I compared variety kinds of methods to allocate memory, instantiate objects.

First, time (measured by GTimer) for simple function call and malloc() for memory block size from 1 byte to 4096 bytes (10000000 times, filled with 0).
Running /c/function-call: 0.021170
Running /glibc/malloc-1: 0.219563
Running /glibc/malloc-2: 0.230215
Running /glibc/malloc-4: 0.230895
Running /glibc/malloc-8: 0.229907
Running /glibc/malloc-16: 0.230143
Running /glibc/malloc-32: 0.229533
Running /glibc/malloc-64: 0.233589
Running /glibc/malloc-128: 0.339241
Running /glibc/malloc-256: 0.367186
Running /glibc/malloc-512: 0.378847
Running /glibc/malloc-1024: 0.462973
Running /glibc/malloc-2048: 0.632350
Running /glibc/malloc-4096: 1.035098

Memory blocks allocattion with C++ new (slower than malloc())
Running /cpp/new-1: 0.256522
Running /cpp/new-2: 0.272629
Running /cpp/new-4: 0.273250
Running /cpp/new-8: 0.271994
Running /cpp/new-16: 0.273642
Running /cpp/new-32: 0.273791
Running /cpp/new-64: 0.275390
Running /cpp/new-128: 0.411459
Running /cpp/new-256: 0.419235
Running /cpp/new-512: 0.428046
Running /cpp/new-1024: 0.490950
Running /cpp/new-2048: 0.664513
Running /cpp/new-4096: 1.001932

Instantiate C++ objects, function calls and virtual function calls
Running /cpp/myclass/new: 0.255105
Running /cpp/myclass/empty-func: 0.021283
Running /cpp/myclass/empty-vfunc: 0.023413
Running /cpp/myclass2/new: 0.283935
Running /cpp/myclass2/empty-func: 0.021643
Running /cpp/myclass2/empty-vfunc: 0.024046
Running /cpp/myclass3/new: 0.363818
Running /cpp/myclass3/empty-func: 0.021251
Running /cpp/myclass3/empty-vfunc: 0.023282

Memory blocks allocation with g_slice_alloc(), g_slice_alloc0(), g_malloc(), g_malloc0() (GSlice slower than malloc() and C++ new, why?)
Running /glib/gslice/alloc-1: 0.605888
Running /glib/gslice/alloc-2: 0.604701
Running /glib/gslice/alloc-4: 0.605113
Running /glib/gslice/alloc-8: 0.605249
Running /glib/gslice/alloc-16: 0.612099
Running /glib/gslice/alloc-32: 0.618420
Running /glib/gslice/alloc-64: 0.644600
Running /glib/gslice/alloc-128: 0.659960
Running /glib/gslice/alloc-256: 0.676860
Running /glib/gslice/alloc-512: 0.729738
Running /glib/gslice/alloc-1024: 0.929127
Running /glib/gslice/alloc-2048: 0.944801
Running /glib/gslice/alloc-4096: 1.306217
Running /glib/gslice/alloc0-1: 0.609936
Running /glib/gslice/alloc0-2: 0.624161
Running /glib/gslice/alloc0-4: 0.624876
Running /glib/gslice/alloc0-8: 0.621272
Running /glib/gslice/alloc0-16: 0.621430
Running /glib/gslice/alloc0-32: 0.622077
Running /glib/gslice/alloc0-64: 0.642180
Running /glib/gslice/alloc0-128: 0.662391
Running /glib/gslice/alloc0-256: 0.676020
Running /glib/gslice/alloc0-512: 0.732908
Running /glib/gslice/alloc0-1024: 0.933038
Running /glib/gslice/alloc0-2048: 0.958885
Running /glib/gslice/alloc0-4096: 1.313431
Running /glib/malloc-1: 0.242182
Running /glib/malloc-2: 0.258160
Running /glib/malloc-4: 0.258030
Running /glib/malloc-8: 0.257849
Running /glib/malloc-16: 0.257843
Running /glib/malloc-32: 0.261680
Running /glib/malloc-64: 0.260929
Running /glib/malloc-128: 0.435186
Running /glib/malloc-256: 0.461474
Running /glib/malloc-512: 0.471338
Running /glib/malloc-1024: 0.623652
Running /glib/malloc-2048: 0.648394
Running /glib/malloc-4096: 0.984106
Running /glib/malloc0-1: 0.265084
Running /glib/malloc0-2: 0.265055
Running /glib/malloc0-4: 0.263465
Running /glib/malloc0-8: 0.264242
Running /glib/malloc0-16: 0.263316
Running /glib/malloc0-32: 0.265759
Running /glib/malloc0-64: 0.270882
Running /glib/malloc0-128: 0.476181
Running /glib/malloc0-256: 0.500356
Running /glib/malloc0-512: 0.516236
Running /glib/malloc0-1024: 0.650716
Running /glib/malloc0-2048: 0.679370
Running /glib/malloc0-4096: 1.013044

test case for g_object_new()
Running /glib/object/new: 6.005563

I have profiled test case of g_object_new() with perf and found that a lot of time is spent on locking/sync mechanism: 27.28% spent on gbitlock.c, 15.23% gthread-posix.c, then type system: 17.3% gtype.c, 7.9% gobject.c, and dataset accessing: 17.6% gdataset.c
Comment 3 Derek Dai 2013-07-08 22:23:12 UTC
Hi, the test case for g_object_new() is simple

#define N_ALLOC				(10000000)
GType type = G_TYPE_OBJECT;

gsize i;
for(i = 0; i < N_FUNC_CALL; i ++) {
	g_object_unref(g_object_new(type, NULL));
Comment 4 GNOME Infrastructure Team 2018-05-24 15:28:34 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: