Re: [lmi] Horrible std::regex performance

[Vadim Zeitlin]

On Mon, 11 Jul 2016 22:18:23 +0000 Greg Chicares <address@hidden> wrote:

GC> The only one where speed matters is 'test_coding_rules.cpp', and there it
GC> does matter very much.

 Yes, I suspected as much. And it's already quite slow for me (which is why
I avoid running "make check_concinnity" manually too often and rely on the
git hook running the coding rules tests only on the files being committed,
which is much faster).

GC> Would it be easy for you to time that by measuring
GC> the 'check_concinnity' target with both regex implementations?

 Yes, sure, I'll do this soon and will also compare them with the
parallelized version.

GC> Even if this makefile line:
GC>     @-$(TEST_CODING_RULES) *
GC> is a bottleneck, perhaps it could be parallelized.

 This is an intriguing idea and should definitely help with many files. I
wish I would have thought to propose this myself, but as I didn't, I'll try
to at least implement it.

GC> MinGW-w64 does seem to offer gcc-6.10, but their sourceforge site is so
GC> painful to navigate that I can't easily tell whether they have it in the
GC> 32-bit sjlj flavor we want. However, we ardently desire to move all
GC> development to GNU/Linux, and debian's cross-compiler offerings
GC>   https://packages.debian.org/search?keywords=mingw-w64
GC> are limited to 4.9.1 stable and 5.4.0 unstable, and upgrading from the
GC> 4.9.1 we use today to 5.4 doesn't seem attractive--with the new gcc
GC> version-numbering scheme, that's not a big jump.

 Just for completeness sake: one important advantage of updating to 5.4
would be that it includes experimental::filesystem library so, even though
it doesn't have full C++17 support, we should, in principle, be able to use
the new standard filesystem API and get rid of boost::filesystem.

GC> I tried searching the web, and didn't immediately turn up anything that
GC> would suggest the developers are aware of this speed problem.

 Maybe not developers, but I did find many discussions about it, so it
doesn't look like it's anything really particular to our use of it.

GC> I find nothing relevant at
GC>   https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=regex
GC> either. It looks like they have more urgent problems with std::regex
GC> anyway, and it doesn't seem wise to hope this problem will go away
GC> anytime soon.

 You're probably right. I'm still astonished by the huge difference between
Boost.Regex and std::regex though, I just don't understand what could have
motivated g++/libstdc++ authors to write a new implementation so much
slower than the existing one they could have used.

 Thanks for your answer and I'll try to implement your suggestions a.s.a.p.,
VZ