<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi,</div><div><br></div><div>I was successful in making CMake work with PCRE. As expected, it was straightforward.</div><div><br></div><div>The problem is that PCRE is also slow. So, I tested the same string and regex with multiple different libraries in order to assess performance. </div><div><br></div><div>The regular expression in question is:</div><div> ([^:]+): warning[ \t]*[0-9]+[ \t]*:</div><div><br></div><div>The string is a 6k character string, a typical compiler command line. (See my first message for sample code).</div><div><br></div><div>For each library the steps are:</div><div> - regcomp() the regular expression </div><div> - regexec() the expression on the string </div><div><br></div><div>Here is how much time it takes to process the string *one* time:</div><div> current CMake -- 860ms</div><div> TRex -- 680ms </div><div> PCRE -- 610ms ( with pcre_exec() )</div><div> PCRE -- 990ms ( with pcre_dfa_exec() ) </div><div> re2 -- 0.085ms</div><div> /usr/include/regex.h -- 0.075ms</div><div><br></div><div>As it can be seen re2 and the standard regex.h are orders of magnitude faster in executing this particular regular expression. </div><div><br></div><div>The difference between PCRE and re2 is also confirmed by this study:</div><div> <a href="http://swtch.com/~rsc/regexp/regexp3.html">http://swtch.com/~rsc/regexp/regexp3.html</a></div><div><br></div><div>CONCLUSTION:</div><div> - PCRE is not fast enough</div><div><br></div><div>QUESTION:</div><div> - is there a reason we shouldn't use the standard regex.h?</div><div><br></div><div>sincerely,</div><div>Alex Ciobanu</div><div><br></div><div><br></div><div><br></div><div><div>On 2011-11-15, at 10:30 AM, Pau Garcia i Quiles wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br><br>If it's of any help, I used the pcrecpp library by Google (it's part<br>of PCRE). With pcrecpp, most operations were only 1-3 lines long. The<br>only problem I found is PCRE provided no way to get the previous/next<br>match, which CMake needs.<br><br><br><br>On Tue, Nov 15, 2011 at 4:25 PM, Alexandru Ciobanu<br><<a href="mailto:alex@rogue-research.com">alex@rogue-research.com</a>> wrote:<br><blockquote type="cite">Hi Bill and Pau,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I am currently working on adding PCRE to CMake. Chances are very hight that it will work, given the very similar comp()/exec() API calls in both implementations.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'll let you know about the results soon.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Alex<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 2011-11-14, at 10:31 PM, Bill Hoffman wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On 11/14/2011 6:08 PM, Pau Garcia i Quiles wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Bill,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think the current incarnation of regexps in CMake should be kept for<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">compatibility reasons.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Yes, of course.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Adding PCRE is not difficult, just time consuming. The implementation<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'd do would be an additional abstraction layer:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- For the current BRE implementation, it would be a 1:1 call match<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- For the PCRE implementation, it would keep match status, count,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">next/previous iterators, etc.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So, for this case I would be interested to here from Alex to see if swapping out the regex will fix the ctest performance issue. It is a nice isolated place to give PCRE a try.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-Bill<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Powered by <a href="http://www.kitware.com">www.kitware.com</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ">http://www.cmake.org/Wiki/CMake_FAQ</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Follow this link to subscribe/unsubscribe:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers">http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><br><br><br>-- <br>Pau Garcia i Quiles<br><a href="http://www.elpauer.org">http://www.elpauer.org</a><br>(Due to my workload, I may need 10 days to answer)<br></div></blockquote></div><br></body></html>