Re: Performance implications of GRegex structure



[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.

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.

M.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]