Open llllllllll opened 4 years ago
The compilation time is really oddly big. I would like to see the offending code.
Hi all, I believe I've created a minimal working example for this issue. The code indeed takes over a minute to build even without debug symbols. I did not go the extra mile to wait for over 25 minutes on my VM for a version with debug symbols, though I might do just that tommorow.
I believe I pinned down the potential offender: forced inlining of code. I've temporarily changed the definitions of CTLL_FORCE_INLINE and CTRE_FORCE_INLINE & removed forced inlining (patch available here). The benchmark results can be found here - tl;dr: build time goes down to 2 seconds for non-debug version.
Of course what I did is not necessarily a correct way to handle long compile times - my comment is missing:
I am aware that staying away from forced inlining is probably not an option.
Needless to say I might have done something incorrectly. Feel free to point out any issues. E: Alright, I've spotted an error. I'll update the results today. E2: I've tested the provided example on MSVC - x86 Debug build takes few seconds, though x86 Release build runs out of heap space (I have 16 gigabytes of ram - I'd expect it to be enough). E3: Clang 9.0 takes ~a minute to build with "-g -O3" - even with enabled forced inlining.
E4: I've updated the build benchmark results with the output of gcc's -ftime-report (available here). As you can see, 86% of the time is spent in phase "trivially dead code". This is just my gut feeling, but disabling forced inlining might help as non-inlined functions are optimized just once/left for runtime evaluation. Though I'm also curious why clang/msvc don't have the same issue. AFAIK MSVC runs local optimizations after inlining and Clang/GCC do so before inlining pass - hence I'd expect clang to have the same problem as gcc. As mentioned in E3 though, clang's builds are within "sane" build time range.
Hi, I've spottedthis issue in latest MSVC 2019 (19.26.28806) now, except the debug compilation is fine, but in release (/Ox flag) the compilation never ends. Removing inlining indeed unblocks it.
@Archie3d does it happen for any pattern? if not, please provide your test case.
@hanickadot no, the shorter the pattern the faster it compiles. For this one it takes forever:
static constexpr auto pattern = ctll::fixed_string { "^([a-z]+)://(([\\w\\-\\.]+)(:([\\w\\-\\?&=]+))?@)?([\\w\\-\\.]+)(:(\\d+)+)?(/[\\w\\.\\-/\\?\\(\\)&=%~]*)?$" };
though when I remove the trailing groups the compilation goes faster (than my patience wears out :)
Compilation flags (MSVC2019):
/EHsc /std:c++latest /bigobj /Ox
clang does not seem to suffer though.
That's a problem of MVSC and their constexpr evaluator :( It's not forever only too long. It's definitely a different issue than #78, please create a new one.
This issue about MSVC creating a lot of debug symbols.
+1 for the patch provided by @osiewicz , it cut my build times down from 4 mins to 11 seconds with clang, and from 3 mins to 12 seconds with gcc. I wonder if this could be merged with a macro to override the default inlining behaviour for better build times?
First, thanks for this wonderful library. I am amazed at how fast it can match and isolate groups!
I was evaluating using ctre for some datetime parsing, like you have in the readme; however, I am finding that the compile times are extremely long when emitting debugging symbols. I have a file, which does have some other medium weight templates, but with only 3 regex literals in the file, the compilation time goes from less than a minute to 22 minutes. Without debugging symbols, it only takes 25 seconds, so I don't believe that it is due to slowness in the library itself.
I am compiling with gcc 9.1.0, and the 3 regular expressions I am using are:
I would like to add many more formats, but I am waiting to implement that until I know what is going on with the compile times. This project is currently using C++ 17 and only gcc, so I am using the
_ctre
UDL. In testing, I have tried the C++20 cnttp version and noticed that it is a bit faster. I am not really able to reproduce this when I just compile the longest regex standalone, so I am wondering if there is a weird interaction with the existing code somewhere.I would like to preserve debugging symbols if possible, and if needed I could try just moving all the ctre stuff to its own object without symbols, but I am wondering if there is something else to try? If it would help, I can see about getting the actual offending code to you on Monday.