inline unicode()

[Harri Porten]

On Mon, 10 Mar 2003, Darin Adler wrote:

> It's a simple practical issue. We do our development builds with -O0 so 
> with no inlining. The functions that get right at the value of the 
> UChar are so hot, that if we leave them calling the inline function, 
> it's noticeably slower, and also more annoying to debug.

OK. I do understand the debugging argument. But I hope you are basing your
optimization work on the debug version. It's not like the behaviour would
vary linearly or even monotonous.

> Since UChar does not provide any abstraction on top of the unicode 
> value, I don't find one or the another any more or less elegant. 
> There's a big practical day-to-day development advantage for us to have 
> this code still be relatively fast when we're working on Safari.

OK.

> This seems to be a rather nitpicky thing to have different in our two 
> source trees, so I'd urge you to consider rolling in these changes 
> unless you find them extremely distasteful.

The changes are already in I think and I don't want to be responsible for
a wide spread diff. In this case I can live with them. But I urge
everybody to respect the importance of nice code. Apple wouldn't have
picked up khtml/kjs if it were written with nothing but speed as the
foremost goal from the beginning.

Thanks for the explanation,

Harri.