Re: [PATCH] Fix memory leaks in scanner

[Santtu Lakkala <inz inz fi>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David,

On 06/03/14 13:59, David King wrote:
> At a glance, it looks much better with the regexes! If the
> performance is similar, I think it should be fine. The many
> man-hours saved during maintenance will be worth any slowdown. ;-)

Scan_Process_Fields_All_Uppercase: 36ms
et_filter_upper: 30ms
Scan_Process_Fields_All_Downcase: 21ms
et_filter_lower: 31ms
Scan_Process_Fields_Letter_Uppercase: 25ms
et_filter_capitalize_first: 338ms
Scan_Process_Fields_First_Letters_Uppercase: 45ms
et_filter_capitalize_words: 408ms
Scan_Process_Fields_First_Letters_Uppercase: 48ms
et_filter_capitalize_words: 1189ms
Scan_Process_Fields_First_Letters_Uppercase: 100ms
et_filter_capitalize_words: 1473ms
Scan_Process_Fields_First_Letters_Uppercase: 94ms
et_filter_capitalize_words: 2242ms
Scan_Process_Fields_Remove_Space: 9ms
et_filter_remove_space: 119ms
Scan_Process_Fields_Insert_Space: 20ms
et_filter_insert_space: 271ms
Scan_Process_Fields_Keep_One_Space: 8ms
et_filter_remove_extra_space: 186ms
Scan_Convert_Underscore_Into_Space: 4ms
et_filter_underscore_to_space: 92ms
Scan_Convert_P20_Into_Space: 4ms
et_filter_p20_to_space: 95ms

These are results for 100000 repetitions for the string "Jehtro Tull"
(first artist that happened to come to mind =). So cannot say, that
performance was "similar", but I'd still say that even 2 seconds for
100 000 iterations is very little compared to other slowdowns.

With simplest kind of caching (put created GRegex-objects in a
GHashTable, with regex itself as key) and using G_REGEX_OPTIMIZE-flag,
the results are noticably better, but still about an order of
magniture slower:

Scan_Process_Fields_All_Uppercase: 38ms
et_filter_upper: 30ms
Scan_Process_Fields_All_Downcase: 17ms
et_filter_lower: 28ms
Scan_Process_Fields_Letter_Uppercase: 23ms
et_filter_capitalize_first: 181ms
Scan_Process_Fields_First_Letters_Uppercase: 47ms
et_filter_capitalize_words: 233ms
Scan_Process_Fields_First_Letters_Uppercase: 46ms
et_filter_capitalize_words: 662ms
Scan_Process_Fields_First_Letters_Uppercase: 91ms
et_filter_capitalize_words: 437ms
Scan_Process_Fields_First_Letters_Uppercase: 101ms
et_filter_capitalize_words: 840ms
Scan_Process_Fields_Remove_Space: 7ms
et_filter_remove_space: 54ms
Scan_Process_Fields_Insert_Space: 21ms
et_filter_insert_space: 158ms
Scan_Process_Fields_Keep_One_Space: 8ms
et_filter_remove_extra_space: 44ms
Scan_Convert_Underscore_Into_Space: 4ms
et_filter_underscore_to_space: 46ms
Scan_Convert_P20_Into_Space: 5ms
et_filter_p20_to_space: 45ms

These results are a bit skewed against current implementations due to
the wrapper mechanism (and hence "forced" g_strdup), but as it's
anyway kicking major regex arse, I'd say it's no biggie.

Now the question remains, is this acceptable performance.

> There is a brief and incomplete description of the coding style in 
> HACKING, but generally it's easier to look at a recent commit, as
> there are sometimes exceptions to the documented style. As long as
> the style is "close enough", I do not mind changing it to match the
> new style, so thanks for trying to get closer to the preferred
> style.

Ahh, somehow I missed the HACKING file in file listing. I will try to
keep to the style mentioned there.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMYbqYACgkQX9Rc0+po4p0vAACfeVNfr76vNryVtrS6zdfHWflm
M9UAn2e/NH2x7vRbVPZ/xZUC+NxvfmnA
=kgT0
-----END PGP SIGNATURE-----