From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <775b8d190702050141k7d64eb82vc5f921e358903a53@mail.gmail.com> Date: Mon, 5 Feb 2007 20:41:27 +1100 From: "Bruce Ellis" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] s_putc and Runes In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Topicbox-Message-UUID: 0d121a28-ead2-11e9-9d60-3106f5b1d025 exactly. time spent optimizing something that uses 3% of the CPU by 10% is better spent going to the beach, or almost anything. On 2/5/07, Russ Cox wrote: > > void > > s_putrune(String *s, Rune r) > > { > > char rbuf[UTFmax]; > > s_nappend(s, rbuf, runetochar(rbuf, &r)); > > } > > This is fine. > > > or as part of the library (where I'm a bit shakier on the semantics): > > > > void > > s_putrune(String *s, Rune r) > > { > > char rbuf[UTFmax]; > > int n; > > if(s->ref > 1) > > sysfatal("can't s_putc a shared string"); > > if (s->ptr >= s->end - n=runelen(r)) > > s_grow(s, n+1); > > (s->ptr) += runetochar(s->ptr, &r); > > } > > Why bother with these details? The above is fine. If it ever > became too slow, the right thing to do would be to fix s_nappend, > not code around everything here. Further, this code is *very* > unlikely to be the bottleneck -- you're calling it once per at most > 3 bytes, so the extra little bit you might or might not be saving > this way pales in comparison to the added complexity. > > The main reason there is no Rune support in the String > library is that it is not widely used. It was written for upas > and later extracted, but the interface is a bit clunky. > > I confess that most of the time, when I need to write to a > growable string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush. > It's just easier, and you get all the print verbs! > > Russ >