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

Ingo Weinhold wrote:
>>If we are -really- concerned about performance, we can inline the
>>'stubby' functions in the header.
> 
> 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.

Excellent point.  I think we should *not* inline anything that isn't 
already inlined.  Again, if later testing shows a performance issue, 
we'll revisit the issue.  In the meantime, the conservative approach is 
best.

e

>>On Thu, Oct 10, 2002 at 07:31:04PM +0200, Jack Burton wrote:
>>  >
>>  > Hi all.
>>  > I hope you all won't be upset by another question :)
>>  > I'm approaching the completion of BString (some methods are well 
>>
>>>tested,
>>
>>  > other aren't, and a pair aren't implemented, but it will be in 
>>
>>>short
>>
>>time),=
>>  >
>>  > and I was wondering.... Often I have some function which are 
>>
>>>similar,
>>
>>for
>>  > example:
>>  >
>>  > 1. Prepend(const char *string)
>>  >
>>  > and
>>  >
>>  > 2. Prepend(const BString &string).
>>  >
>>  > These functions call a private utility function (_DoPrepend),
>>  > but I am thinking if it would be better for the (2) to just call 
>>
>>>the
>>
>>first
>>  > (i.e.
>>  >
>>  > Prepend(const BString &string)
>>  > {
>>  > =09Prepend(string.String());
>>  > }
>>  >
>>  > Yes, this mean a little performance loss, but it would have the
>>undubious
>>  > vantage that there would be less code =3D=3D less bugs.
> 
> 
> I don't see why there would be less code. I would say, it's the same 
> (maybe one line difference depending on were the strlen() is used)... 
> unless you count the mere existence of a function real code.
> 
> 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.
> 
> Regarding Erik's `premature optimization is the root of all evil': I 
> couldn't agree more. But in this case it's only about calling strlen() 
> inside the worker function or supplying the length as a parameter, 
> allowing the `optimization' to use Length() instead of strlen() for the 
> BString parameter. Anyway, in my opinion this optimization should 
> definitely be used in the production code.
> 
> 
>>  > Anyway, this is just an example, and I would be glad if someone 
>>
>>>took a
>>
>>  > moment and threw a look to our BString implementation, to 
>>
>>>understand
>>
>>  > what I= am saying.
> 
> 
> I would argue similarly for the other methods. The R1 release code 
> should use the optimizations. BTW, for two Append() versions and `+=' 
> you don't even have a choice, as they are implemented inline.
> 
> CU, Ingo
> 
> 
>

Other related posts: