GNOME Bugzilla – Bug 151957
inlined g_str_has optimisations
Last modified: 2018-05-24 10:33:06 UTC
gcc is able to emit optimized code for (str|strn|mem)cmp( str, "litteral" ). The current g_str_has_prefix / g_str_has_suffix does not allow this. I think using g_str_has_*( str, "litteral" ) is a pretty common usage and worths this optimisation. the following patch renames g_str_has_* to _g_str_has_* and defines 4 macros ( 2 to prevent multiple argument evaluation ) some benchmark results (debian gcc-3.4 -O2) for(i = 0; i < 100000000; ++i) { res += g_str_has_prefix(s, "Stargate"); res += g_str_has_suffix(s, "Stargate"); res += g_str_has_prefix(s, "Super"); res += g_str_has_suffix(s, "docious"); } PPC G4 1GHZ orig 65s -> patched 22s XP 1,666GHZ orig 37s -> patched 16s please, consider this patch.
Created attachment 31319 [details] [review] inline
Comment on attachment 31319 [details] [review] inline The patch won't work as is, since _-prefixed functions are not exported, thus can't be used in public macros. Also __extension__ should not be directly used, we have a macro for that.
what about introducing 2 new macros : g_str_starts_with and g_str_ends_width ?
I like the idea, but renaming the functions as the patch does is an ABI break (existing binaries would fail to run with the new glib). The way to go would be to introduce new macros g_str_starts/ends_with including the gcc optimization. Also note that you didn't modify glib.symbols so your patch can't compile as-is.
Created attachment 155954 [details] Iterate g_str_has_prefix/suffix a 100000000 times A complete test case for convenience
Created attachment 155956 [details] [review] Optimize g_str_has_prefix/suffix updated This is an updated patch, which actually compiles, but it still breaks ABI.
Created attachment 155969 [details] [review] Intorduce macros g_str_starts/ends_with
I think it should be possible to keep the existing functions (g_str_has_[prefix|suffix]()) and their exported symbols, and just define two macros with the same names (g_str_has_[prefix|suffix]()) in the case that GCC is being used and extensions are available. As long as the names of the functions are protected in brackets in their declarations and calls, everything should work OK. This is what we do with (for example) g_object_ref() and g_object_ref_sink() to add type propagation for them. (See commit 3fae39a5d742afe73741f5fd7aa24e3ae8182f06, for example.)
-- 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: https://gitlab.gnome.org/GNOME/glib/issues/24.