digitalmars.D - Anything new about std.regex's compilation times?
- Emmanuelle (3/3) Oct 27 2019 https://issues.dlang.org/show_bug.cgi?id=18378
- H. S. Teoh (10/14) Oct 28 2019 I haven't heard anything. The last time Dmitry (the one who wrote
- bachmeier (4/8) Oct 28 2019 I like std.regex because it supports arbitrary lookbehind. It's
- H. S. Teoh (14/23) Oct 28 2019 I like std.regex too! It's just that it comes at a hefty compile-time
- Emmanuelle (2/10) Oct 30 2019 I think .NET's regex engine allows arbitrary lookbehind too.
- bachmeier (6/9) Oct 28 2019 Does that apply only to compile time regex? I recently added
https://issues.dlang.org/show_bug.cgi?id=18378 Importing std.regex still triples compilation times. Anything new on that front?
Oct 27 2019
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
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
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: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. -- RLIt'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
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:I think .NET's regex engine allows arbitrary lookbehind too.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 30 2019
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