Do we need faster regex?

[Dmitry Olshansky]

On Tuesday, 26 December 2023 at 15:58:03 UTC, BoQsc wrote:
> The focus should always be on slower but more maintainable and 
> simple implementation.
>

Agreed on simple, though humbly disagree on speed.

> The efficiency and speed should be left for specific cases 
> where it is needed and, again with as much clarity as possible.
>
> Support and Features over efficiency and speed.
>

Well we already have std.regex which is quite fast and feature 
rich, sadly simplicity is not an option if we are to support full 
ECMAScript regex language and basic level 1 unicode regex.


> The question of "is anyone even using that?" is a wrong 
> question.
> If it's a common behaviour among implementations, it should 
> exist.
>
RE2 specifically avoids complicated features that block design of 
a fast engine.

> If behaviour makes sense, it should exist and not avoided to be 
> implemented just to gain some fraction of speed that can be 
> gained in other ways or again, using more specific 
> implementation for the job.
>
> If you think that your implementation can be grown into 
> supporting all crucial features, then it should be a good draft 
> for other people to explore and complete implementation.

There are very few folks who want to develop regex engine I 
think. Encouraging collaboration is an interesting angle I did 
not account for.


> Else it should be a specific case implementation that could be 
> selected if there is a need for speed but with the sacrifice of 
> features.

Okay, I understand your points. For the most part I could 
summarize my point of view as follows.
Building regex engine without regard for speed is not challenging 
for me, nor do I think that a simple slow engine could be 
gradually improved into simple fast engine. Speed is something 
you have to think of laying the first brick of whatever you are 
building, iff speed is desired.

—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me