[Geany-devel] About disabling GTK+/GLib deprecated symbols

[Enrico Tröger]

On Thu, 23 Oct 2008 18:57:09 +0200, Enrico Tröger
<enrico.troeger at uvena.de> wrote:


>>About the g_strcasecmp() problem:
>>I don't think the right solution is to copy the old, broken code from
>>GLib into Geany. As the docs mention, there is a reason why this
>>function is deprecated and should not used.
>>IMO we should rewrite the code which uses this function with the
>>alternative functions mentioned in the docs.
>
>Update:
>Yesterday, I did some work on this and wrote utils_str_casecmp() which
>uses g_utf8_casefold() and g_utf8_collate() as suggested in the GLib
>API docs. It seems to work, for simple examples actually better than
>g_strcasecmp().
>But the new code is noticeably slower, about factor 100 (!).
>
>When starting Geany with a fresh configuration and opening about 30
>files with different filetypes, we almost have 1000 calls to this
>function (by only counting calls which actually pass g_utf8_collate()).
>(we could eliminate many of these calls by changing utils_atob() to be
>case-sensitive or something smarter, this is used when reading the
>filetype definition files to evaluate false/true strings into
>booleans, maybe it's enough to check for true and TRUE, and treat
>anything else as false.)
>
>I've attached a testcase with some simple test strings to test the
>correctness of both implementations. These show the new code works
>better but please note that the code uses only simple example strings,
>without more complex unicode characters).
>
>The testcase additionally does some speed comparisons of both
>functions, so you can easily see the big difference in execution time.
>Simply change the value of the CALLS macro to change the amount of
>calls of both functions.
>Note: the gap in execution time of both implementations might be even
>bigger if the test strings are not encoded in UTF-8 but any other
>encoding and so have to be passed through g_locale_to_utf8().
>
>Conclusion:
>I'm not sure anymore if it's worth to use this code because of the
>execution time. Assuming (read: hoping) that most users will use
>Ascii-only characters in filenames (for which the code is mostly used)
>it maybe isn't worth.
>OTOH utils_str_casecmp() can surely be still improved to get it run
>faster.

There is another possibility :

see the attached testcase, an updated version of the first one. It has
an additional variant of the code, utils_str_casecmp_easy() which
simply converts the strings to compare into lowercase using
g_utf8_strdown() and then compare them with strcmp().
This is to some extend also 'broken' because it doesn't take different
locale-specific case sorting rules into account. But therefore it is
noticeable faster than the full variant. It's only about ten times
slower than g_strcasecmp() which is IMO not that bad and so I'm
thinking this could go in.


Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strcasetest.c
Type: text/x-csrc
Size: 4607 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20081025/4cfb79c5/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20081025/4cfb79c5/attachment.pgp>