4 ms·
I have to reiterate this; don't do it -- sort order changes and you'll run into other mysterious issues. It's not worth the "performance improvement".
by binarycrusader 11y ago
I have to reiterate this; don't do it -- sort order changes and you'll run into other mysterious issues.
It's not worth the "performance improvement".
- cle 11y agoIn some cases, it certainly is worth the improvement. Performance improvements translate into $$$. Knowing that "LC_ALL=C can improve performance but cause UTF problems" is awesome information to base a design on. A blanket statement like "never use LC_ALL=C" is not.
- binarycrusader 11y agoShort of a bug or other pathological issue, if you resort to messing with locale just to avoid a performance problem, you're likely to hide other issues that will cause problems whenever another user attempts to do the same thing and it breaks. Again, not worth it -- if only for performance sake, generally speaking.
- unhammer 11y agoThere are good reasons to use LC_ALL=C for certain commands, especially if you want sorting that's stable across different systems. Sometimes you want "aa" to be before "b" even though the Norwegian UTF-8 locale puts it after "å" (which comes after "…zæø"): $ echo $'a\naa\nb\nå'| LC_ALL=C sort a aa b å $ echo $'a\naa\nb\nå'| LC_ALL=nn_NO.UTF-8 sort a b å aa Even worse, some characters that are byte-different collate the same: $ echo $'∨\n∧'|LC_ALL=C sort -u ∧ ∨ $ echo $'∨\n∧'|sort -u ∨ Handling Unicode sanely requires understanding some Unicode.
- binarycrusader 11y agoI'm well aware of that, but in general, don't do it still applies :-) In general, I'd never do it for performance only, it would have to involve one of the issues you've pointed out (there are some components I build that require it, erroneously IMO).