[interfacekit] Re: [Fwd: Message submitted to 'interfacekit']

On 2002-10-11 at 19:44:10 [+0200], you wrote:

> We should be very careful with inlining functions. Unless the 
> functions's tasks are trival (as BString::Length()/String() are for 
> example), the function call overhead to function execution ratio should 
> be insignificantly small. And inlining may introduce serious binary 
> compatibility traps.

Yes, but inlining some class private methods won't introduce any binary 
compatibility problems, and could help improving performance, even if some 
of these functions are, IMHO, too big to be inlined. The _Init() method 
could be inlined, but I wouldn't inline the _OpenAtBy() or the _GrowBy().
 
> Regarding the performance loss: BString is a high-performance class. It 
> trades space (the length field in _privateData) for performance. I 
> would say, however you implement it now, the final code should take 
> advantage of this length field.

Yeah, of course.
It's already taking advantage of it.

BTW, I brought a bad example. A better example would be the two 
CharacterEscape function. If you take a look on them, you will understand 
what I want to say (and if you don't have time, I will explain more the 
next time) :)

Other related posts: