www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Anything new about std.regex's compilation times?

reply Emmanuelle <VuLXn6DBW PPtUm7TvV6nsw.com> writes:
https://issues.dlang.org/show_bug.cgi?id=18378

Importing std.regex still triples compilation times. Anything new 
on that front?
Oct 27 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 28, 2019 at 01:51:39AM +0000, Emmanuelle via Digitalmars-d wrote:
 https://issues.dlang.org/show_bug.cgi?id=18378
 
 Importing std.regex still triples compilation times. Anything new on
 that front?
I haven't heard anything. The last time Dmitry (the one who wrote std.regex) mentioned this, he said he was going to look into how to fix the problem. But I haven't heard anything since then. It's kinda sad because std.regex used to be touted as the fastest regex engine even compared to other regex libraries. But it seems others have caught up since while we've stagnated. :-/ T -- Guns don't kill people. Bullets do.
Oct 28 2019
parent reply bachmeier <no spam.net> writes:
On Monday, 28 October 2019 at 16:23:07 UTC, H. S. Teoh wrote:

 It's kinda sad because std.regex used to be touted as the 
 fastest regex engine even compared to other regex libraries. 
 But it seems others have caught up since while we've stagnated. 
 :-/
I like std.regex because it supports arbitrary lookbehind. It's the most powerful regex engine I've used, but maybe I live a sheltered life.
Oct 28 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 28, 2019 at 06:14:26PM +0000, bachmeier via Digitalmars-d wrote:
 On Monday, 28 October 2019 at 16:23:07 UTC, H. S. Teoh wrote:
 
 It's kinda sad because std.regex used to be touted as the fastest
 regex engine even compared to other regex libraries. But it seems
 others have caught up since while we've stagnated. :-/
I like std.regex because it supports arbitrary lookbehind. It's the most powerful regex engine I've used, but maybe I live a sheltered life.
I like std.regex too! It's just that it comes at a hefty compile-time cost. Even non-ctRegex already significantly slows down compilation, apparently due to heavy template use in its implementation, if you use ctRegex be prepared for BIG compile time slowdown. Though last I heard, Dmitry has said that ctRegex is actually slower in practice than regular regex, so I've pretty much given up on ctRegex and only use "runtime" regexen now. AFAICT, the slowdown was caused by the last major revamp of std.regex (the older version was somewhat faster, compile-time-wise), and I filed a bug for it, but not much progress has been seen since then. T -- You have to expect the unexpected. -- RL
Oct 28 2019
prev sibling parent Emmanuelle <VuLXn6DBW PPtUm7TvV6nsw.com> writes:
On Monday, 28 October 2019 at 18:14:26 UTC, bachmeier wrote:
 On Monday, 28 October 2019 at 16:23:07 UTC, H. S. Teoh wrote:

 It's kinda sad because std.regex used to be touted as the 
 fastest regex engine even compared to other regex libraries. 
 But it seems others have caught up since while we've 
 stagnated. :-/
I like std.regex because it supports arbitrary lookbehind. It's the most powerful regex engine I've used, but maybe I live a sheltered life.
I think .NET's regex engine allows arbitrary lookbehind too.
Oct 30 2019
prev sibling parent bachmeier <no spam.net> writes:
On Monday, 28 October 2019 at 01:51:39 UTC, Emmanuelle wrote:
 https://issues.dlang.org/show_bug.cgi?id=18378

 Importing std.regex still triples compilation times. Anything 
 new on that front?
Does that apply only to compile time regex? I recently added std.regex for some simpler matching/replacing and I can't tell the difference in compile times. I didn't measure, but since I avoid templates as much as possible, my compile times are already fast and they remained fast after adding std.regex.
Oct 28 2019