> Another example of a hidden "cost" of Rust comes from things like Unicode support. Recently I tested a regex-heavy algorithm that used burntsushi's regex library for Rust. In initial testing, Java blew it away. What I later realized was that the default Java implementation I used did not support Unicode characters. When I enabled that support, and enabled incremental GC (to support the scale of testing I was performing), the performance was similar.
Could you explain a bit more about this? I find it surprising. If you can't share the code, perhaps you could share the regexes? Which Java regex engine did you use? (There really should only be one case where Unicode support causes performance problems, and that's when you use word boundaries.)
Thanks! If you come up with an example I'd love to see it.
Generally, even though `\w` in Rust's regex library supports Unicode, it shouldn't result in a slow-down compared with the non-Unicode `\w`, assuming you're using find_iter. (Of course, Unicode support isn't free, but the primary cost here is memory and compile time, not matching performance.)
If you were indeed emitting `String` (a new allocation for every match) instead of `&str`, then that could certainly be a possible explanation for the slow down.
Could you explain a bit more about this? I find it surprising. If you can't share the code, perhaps you could share the regexes? Which Java regex engine did you use? (There really should only be one case where Unicode support causes performance problems, and that's when you use word boundaries.)