The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12580
==
Reported By:arrowdodger
Assigned To:
On 11/16/2011 9:05 AM, OKUMURA Yuki wrote:
(Sorry Bill, i repost here..)
2011/11/16 Bill Hoffmanbill.hoff...@kitware.com:
- snip -
What type of evolution will Ninja need? I suppose it could use cmake
scripts and exectue_process which can do type things pretty easy.
Why not insert cmd /c
Hi,
I was successful in making CMake work with PCRE. As expected, it was
straightforward.
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.
The regular expression in question is:
([^:]+):
Just looking at the calendar...
Three short weeks from today, we are planning to schedule the build
and upload of CMake 2.8.7-rc1 so all of you can give it a try.
Followed by weekly rc's as needed until the final official release of
CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011.
If you are
Hi Brad,
[1]
On 11/16/2011 12:44 PM, Alexandru Ciobanu wrote:
For each library the steps are:
- regcomp() the regular expression
- regexec() the expression on the string
Can you time each of these steps separately for each library? I would not
be surprised if the compilation time is the
On Wednesday 16 November 2011, Alexandru Ciobanu wrote:
Hi Brad,
...
Advantages of TRE:
- API very similar to standard regex.h (i.e. easy to integrate with
CMake) - supports wide characters
- compiles on many platforms Windows, AIX, HP-UX, you name it.
What do you think about TRE?
On 11/16/2011 2:12 PM, Alexandru Ciobanu wrote:
This is how I run the tests (pseudocode):
recomp()
repeat 1000 times:
regexec()
Thanks for the explanation.
TRex -- 680ms
PCRE -- 610ms ( with pcre_exec() )
PCRE -- 990ms ( with pcre_dfa_exec() )
re2
A little off topic, but I am wondering if the ctest performance issue
for xcode could be fixed without changing the regex. The problem with
xcode is that it spits out very verbose output. I am wondering if some
short circuit stuff could be put in place. Maybe do a string compare of
the
On 11/16/2011 4:11 PM, Sean McBride wrote:
The downside is that this solution would be fragile. xcodebuild's
output is not guaranteed to be the same forever, it's not like a public
API. Already today, gcc and clang output pretty differently. I'm a
little worried this would bite us.
Besides,
