Summary: | [PATCH] compare strings faster | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | Stanislav Brabec <sbrabec> | ||||||
Component: | Other | Assignee: | users | ||||||
Status: | NEW --- | ||||||||
Severity: | enhancement | ||||||||
Priority: | P3 | ||||||||
Version: | 3.6.1 | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Attachments: |
|
Description
Stanislav Brabec
2008-11-14 16:15:21 UTC
Created attachment 641 [details]
claws-mail-g_strcmp0.patch
(All of these are non-critical codepaths, apart maybe the hunk in summaryview.) The problem with g_strcmp0 is that it's since glib 2.16. We have strcmp2 that does the same internally. You can use any simple function to compare strings. Simply replace g_strcmp0 by strcmp2 before applying my patch. Purpose of the patch: g_utf8_collate() is a ~1000 lines of code run and several temporary memory allocations. Simple comparison may contain ~4 lines of code. If you don't need lexicographical order, g_utf8_collate() is simply an overkill. I have used g_strcmp0(a,b) as it should return zero in exactly the same conditions like g_utf8_collate(a,b): - If strings are equal - If a or b are NULL (In reply to comment #3) > The problem with g_strcmp0 is that it's since glib 2.16. > We have strcmp2 that does the same internally. We now depend on glib >= 2.20, so this problem is no longer a problem. :) (In reply to comment #5) > (In reply to comment #3) > > The problem with g_strcmp0 is that it's since glib 2.16. > > We have strcmp2 that does the same internally. > > We now depend on glib >= 2.20, so this problem is no longer a problem. :) That strcmp2 sounds like a candidate for removal then :) For a carefu(In reply to comment #6) > > We now depend on glib >= 2.20, so this problem is no longer a problem. :) > > That strcmp2 sounds like a candidate for removal then :) For a careful removal - the two functions return slightly different values for various combinations of null and non-null arguments, so a simple s/strcmp2/g_strcmp0/g might cause some breakage. (In reply to comment #7) > For a carefu(In reply to comment #6) > > > We now depend on glib >= 2.20, so this problem is no longer a problem. :) > > > > That strcmp2 sounds like a candidate for removal then :) > > For a careful removal - the two functions return slightly different values > for various combinations of null and non-null arguments, so a simple > s/strcmp2/g_strcmp0/g might cause some breakage. Indeed, just to be sure I've made a little test program which shows what you say: "(null)" "(null)" g_strcmp0 = 0 strcmp2 = -1 "(null)" "abcdef" g_strcmp0 = -1 strcmp2 = -1 "abcdef" "(null)" g_strcmp0 = 1 strcmp2 = -1 "abcdef" "abcdef" g_strcmp0 = 0 strcmp2 = 0 "abcdef" "fedcba" g_strcmp0 = -5 strcmp2 = -5 Since usage is mostly to test != 0, the problematic case is the first one. Not sure if some comparison relies on that inequality, I'll check tomorrow. Otherwise the patch works fine so far :-) Created attachment 1765 [details]
Replace strcmp2 by g_strcmp0
|