[interfacekit] Re: [Fwd: Message submitted to 'interfacekit']
- From: Erik Jaesler <erik@xxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Fri, 11 Oct 2002 11:21:39 -0700
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:
