inline unicode()

[Dirk Mueller]

On Mon, 10 M=E4r 2003, Darin Adler wrote:

> Except that Safari programmers use development builds all day long when=
=20
> doing tasks other than optimization, so the speed does matter a little=20
> bit to us.

premature optimization is the root of all evil.=20

Personally, one of the lessions I've learned so far from developing KHTML i=
s=20
that all hacks backfire sooner or later. Your inlining is nothing more than=
=20
a hack, its not even an optimisation that is worth a penny. I agree its=20
mood to discuss about manually inlining UChar, but in other cases you do=20
want to have the method wrapper to be able to easily make it noninline or=
=20
otherwise more complex in case the implementation has to be changed.=20

Sorry, I hate to be a pain here but coding style is more important than the=
=20
runtime performance of debugging builds. I don't know about your coding=20
skills, but I tend to waste a lot more time on thinking about the code and=
=20
browsing files to find a bug than waiting for the compiler. And sacrifying=
=20
coding style certainly won't make the brain-based jump-around time to=20
become any smaller.=20


--=20
Dirk