> You only pay the space cost if you use it, similar to the nls tables. The way Linux module loading works these things are loaded by default, not when someone needs it. So no, you (or rather every unfortunate Linux XFS user) would pay it always, unless you black list the module or rebuild the kernel. > A big part of the table does decompositions for Korean: eliminating > the Hangul decompositions removes 156320 bytes, leaving 89936 bytes. Are there regular ranges or other redundancies in the Korean encoding that could be used to compress paths? Doing some basic research other people already answered this: Please use the ICU or google tables referenced below. Apparently smaller is possible too, but 40-50k seems more reasonable. I'm just gonna make the claim that whatever performance you get from a larger table is dwarfed by the cache miss overhead. ---- http://macchiato.com/unicode/normalization_footprint.htm http://www.macchiato.com/unicode/nfc-faq NFC normalization requires large tables, right? Like many other cases, there is a tradeoff between size and performance. You can use very small tables, at some cost in performance. (Even there, the actual performance cost depends on how often normalization needs to be invoked, as discussed above.) To see an analysis of the situation, see Normalization Footprint. It is a bit out of date, but gives a sense of the magnitude. For comparison, ICU's optimized tables for NFC take 44 kB (UTF-16) and Google's optimized tables for NFC take 46 kB (UTF-8). -Andi _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
