Hacker News Reader

Comment by kibwen | Hacker News Reader

Thanks for the info! In the course of this conversation I've also been made aware of the globset crate, by the same author as the regex crate: https://crates.io/crates/globset . I'm going to start a conversation about seeing whether anybody might want to start deprecating glob in favor of globset, in the interest of having just one "blessed" library for this.

View on HN

FWIW, the globset crate works by converting globs to regexes (so it is therefore also linear time). The downside is that you need to pay the overhead of regex compilation. In general, it should be pretty small since globs probably don't result in huge regexes, but I bet compilation is slower than what's in the `glob` crate currently. (I've never benchmarked it though, so I'm just guessing.)

Doesn't your regex crate avoid compilation of various types of "simple" regexes, and instead just translates them to simple string library calls? If so, wouldn't most globs be converted to such?

You have the general idea right in that the matching routine itself might completely avoid the regex engine. But that doesn't mean the implementation saves every possible instruction during compilation. For the most part, compilation is assumed to be amortized somehow, so as long as it's reasonable, not much work has gone into making it as fast as possible.

I assume compiling/translating globs to regexp also takes some time. I wonder if that could be meaningful in some pathological cases?

It's meaningful when you can't amortize compilation. I wouldn't call those pathological, but they seem niche.

The translation from glob to regex at the syntax level is likely a non-factor. It's the compilation of the regex that probably starts to matter.

Why just deprecate? Can't it be made to proxy behind the scenes to globset?

Reply on news.ycombinator.com