Optimize case_fold_and_combine_ranges?

[SimonSapin]

I haven’t timed it, but the case_fold_and_combine_ranges function introduced in #78 is probably slow for large sets of character ranges like \p{Lu}. (That is, slow to parse/compile a regex.) It can probably be improved to not consider individual chars when we can determine that none in a given range (or subrange) is affected by case folding.

[BurntSushi]

Yeah, I saw that. I'm not terribly concerned with parsing/compiling performance. I'll take a pass over it in my parser rewrite. (Which I'm doing as part of #29.)

[BurntSushi]

I think I have at least this optimization implemented in the parser rewrite: https://github.com/rust-lang/regex/blob/new-parser/regex_syntax/src/lib.rs#L148

[SimonSapin]

Nice! I feel it could be more clever still, but this seems to be a nice compromise of optimizing some (most common?) cases while keeping it relatively simple. Have you measured it before/after and against case-sensitive for large classes like \p{Lu}?

[BurntSushi]

Not yet. Once I finish the rewrite, I'll add some benchmarks and maybe do some profiling to see if I can pick off low hanging fruit.

But yeah, I feel like the entire way classes are constructed (particularly canoncalizing them) could be more clever. The code is pretty short/clear now though. :)

[BurntSushi]

Weird that github didn't close this. Fixed by #87.