https://issues.dlang.org/show_bug.cgi?id=18378

Importing std.regex still triples compilation times. Anything new on that front?

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.

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.

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.

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

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.