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 795828 - Drop use of GSlice in GStreamer?
Drop use of GSlice in GStreamer?
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-05-05 10:31 UTC by Tim-Philipp Müller
Modified: 2018-11-03 12:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Drop use of GSlice allocator in favour of plain g_malloc()/g_free() (83.66 KB, patch)
2018-05-05 10:31 UTC, Tim-Philipp Müller
none Details | Review
sysmem, buffer, bufferlist: no need to store slice_size any more (6.21 KB, patch)
2018-05-05 10:32 UTC, Tim-Philipp Müller
none Details | Review
Results from Fedora 28 on a ThinkPad x230 (12.05 KB, image/png)
2018-05-05 11:54 UTC, Olivier Crête
  Details

Description Tim-Philipp Müller 2018-05-05 10:31:57 UTC
Created attachment 371701 [details] [review]
Drop use of GSlice allocator in favour of plain g_malloc()/g_free()

Just gonna put this here. Enjoy.

The "Benchmarks show" bit could probably need more verification, but in the few tests I have run I have found either positive performance impact or no discernable performance impact. It's hard to do proper measurements for our purposes, we need to test alloc from one thread and free in another thread for realistic usage, while at the same time having a test case where allocation/free takes up most of the cycles. I have run some tests on a low-powered windows ec2 machine, that showed GSLice being ridiculously slow compared to the system allocator there (windows server 2006 =~ win10).

IIRC main reason to use GSlice was because the sys allocator on ~Windows XP was horrendous, but that doesn't seem to be the case any longer, and on Linux the glibc allocator seems superior nowadays.
Comment 1 Tim-Philipp Müller 2018-05-05 10:32:54 UTC
Created attachment 371702 [details] [review]
sysmem, buffer, bufferlist: no need to store slice_size any more
Comment 2 Olivier Crête 2018-05-05 11:54:54 UTC
Created attachment 371707 [details]
Results from Fedora 28 on a ThinkPad x230

On my setup, GSlice is appreciably faster than malloc(). Even when using tcmalloc, gslice+tcmalloc is even faster!

So I would close this as invalid.
Comment 3 Olivier Crête 2018-05-05 11:55:58 UTC
oh I can't read graphics, tcmalloc is a lot faster than gslice.. But GSlice is fsater than plain malloc...
Comment 4 GStreamer system administrator 2018-11-03 12:46:20 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org'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: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/291.