On Wed, 30 Aug 2000 10:44:55 -0400, Stephen P. Potter wrote: >| Memory usage is irrelevant compared with speed. > >That's interesting. I could swear I've seen people make a tradeoff before, >rather than always just implementing the fastest solution. Nothing is >irrelevant (except resistance, if you're a Borg or a Dalek). If we go to >UTF16 and we start needing gig footprints for tr///, is that going to be OK >with you? If you have a gig footprint, speed will suffer too, and I'm not talking about swapping, but about table initialization, which would take quite a significant time. A quick check at Unicode's site reveals that 3x64k characters ought to be enough, for virtually all current cases (except for the "plane 14" tags). <http://www.unicode.org/unicode/alloc/Pipeline.html> -- Bart.
- Re: RFC 165 (v1) Allow Varibles in tr/// Mark-Jason Dominus
- Re: RFC 165 (v1) Allow Varibles in tr/// Stephen P. Potter
- Re: RFC 165 (v1) Allow Varibles in tr... Bart Lateur
- Re: RFC 165 (v1) Allow Varibles ... Bart Lateur
- Re: RFC 165 (v1) Allow Varibles ... Stephen P. Potter
- Re: RFC 165 (v1) Allow Varib... Mark-Jason Dominus
- Re: RFC 165 (v1) Allow Varib... Stephen P. Potter
- Re: RFC 165 (v1) Allow Varib... Tom Christiansen
- Re: RFC 165 (v1) Allow Varibles in tr... Tom Christiansen
- Re: RFC 165 (v1) Allow Varibles ... Stephen P. Potter
- Re: RFC 165 (v1) Allow Varib... Bart Lateur
- Re: RFC 165 (v1) Allow Varib... Tom Christiansen
- Re: RFC 165 (v1) Allow Varibles in tr... Jonathan Scott Duff
- Re: RFC 165 (v1) Allow Varibles in tr/// Chaim Frenkel
- Re: RFC 165 (v1) Allow Varibles in tr/// Mark-Jason Dominus