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 731756 - gstvalue: Speed up gst_value_intersect/_subtract
gstvalue: Speed up gst_value_intersect/_subtract
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal enhancement
: 1.3.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 731829 731892
 
 
Reported: 2014-06-17 05:56 UTC by Edward Hervey
Modified: 2014-06-19 05:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gstvalue: Speed up gst_value_intersect/_subtract (3.80 KB, patch)
2014-06-17 05:56 UTC, Edward Hervey
committed Details | Review
gtype: G_VALUE_HOLDS optimisation for case where types are different (1.12 KB, patch)
2014-06-17 19:46 UTC, Tim-Philipp Müller
none Details | Review

Description Edward Hervey 2014-06-17 05:56:02 UTC
Both gst_value_intersect and gst_value_subtract will call
gst_value_compare if one of their arguments isn't a list.

gst_value_compare will then re-do a check to see if one of
the arguments is a list (for the special case of comparing a unitary
value with a list of length 1).

The problem is that the various G_VALUE_HOLDS represent an expensive
amount of calling gst_value_compare (almost half of it) to see if
the provided arguments are list. These checks can be done without
when we know that the arguments aren't lists.

* Create a new "pure" gst_value_compare which avoids that special
  case comparision

Benchmarks:
 valgrind/callgrind: average speedup in instruction calls for
 gst_value_intersect and gst_value_subtract is around 56% (Makes 63%
 of the calls it used to take previously)

 tests/benchmarks/capsnego: With default settings (depth 4, children 3
 607 elements), time taken for transition from READY to PAUSED:
   Before : 00.391519153
   After  : 00.220397492
    56% of the time previously used, +77% speedup
Comment 1 Edward Hervey 2014-06-17 05:56:05 UTC
Created attachment 278569 [details] [review]
gstvalue: Speed up gst_value_intersect/_subtract
Comment 2 Tim-Philipp Müller 2014-06-17 14:16:58 UTC
Go for it, but it sounds a bit odd that a bunch of GType comparisons (those are non-subclassable fundamental types, so it should be really cheap) is so expensive. But then there's the G_IS_VALUE() as well I guess.

Maybe call it _nolist() though or _internal() ? 'pure' usually means something else and it's not clear how that applies more to the stripped down compare function than to the public one.
Comment 3 Edward Hervey 2014-06-17 14:21:30 UTC
it's the G_VALUE_HOLDS which is expensive actually.

That calls g_type_check_value_holds() which is expensive :(

I'll rename it to _nolist()
Comment 4 Edward Hervey 2014-06-17 14:27:51 UTC
Attachment 278569 [details] pushed as b0b20b4 - gstvalue: Speed up gst_value_intersect/_subtract
Comment 5 Tim-Philipp Müller 2014-06-17 19:46:20 UTC
Created attachment 278623 [details] [review]
gtype: G_VALUE_HOLDS optimisation for case where types are different

How about this? Takes off another 15-20% for me here.
Comment 6 Edward Hervey 2014-06-18 05:30:16 UTC
Let's open a glib bug for that one ?