On Thu, 2007-03-15 at 10:38 -0400, Morten Welinder wrote: > [Re PCRE] > > > (There is no match[er] object here, but the equivalent is in all the in > > and out parameters ...) > > Is it? If PCRE is as glibc, there is lots of state in the compiled expression > and you cannot use it threaded. However, once the match call is done, > another thread can use the compiled regexp.
PCRE has no relation to glibc, and the man page says: The compiled form of a regular expression is not altered during matching, so the same compiled pattern can safely be used by several threads at once. > > Neither is very appealing to me as a coder, though I could be convinced > > that the second [==re-compile] is OK by suitable performance timings. Do we > > have such numbers? > > It's hard to see what kind of numbers would make sense to use as an argument > here. The numbers will depend heavily (orders of magnitude) on the regexps > and the data. Well, I could imagine (maybe, barely) that someone could show me numbers that showed that with a variety of long and complicated regular expressions, compiling them was still 10x as fast as matching them against very short strings. But in general, yes, part of my concern is that there are situations where you are going to matching the same regular expression against thousands of strings, and in that situation, unless compilation is very, very, fast, the need to repeatedly recompile will inevitably produce measurable overhead. - Owen
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list