Optimizing constructors/destructors for embedded systems

[Daniel Lohmann]

Kövesdi György schrieb:
> 2007. június 25. 12.59 dátummal Daniel Lohmann ezt írta:
>> 1) I am not sure if I understand your problem. Can you give an exampel
>> for such an (automatically generated) destructore that implicitly calls
>> delete?
>>
> It is just a test class:
> 
> class valami
> {
> public:
>     valami();
>     virtual ~valami();
>     virtual void kiir();
>     int adat;
> };
> 
> The source:
> 
> valami::~valami()
> {
> }
> 
> Those instances of destructors are generated:
> 
> 00000142 <valami::~valami()>:
>  142:   fc 01           movw    r30, r24
>  144:   84 e0           ldi     r24, 0x04       ; 4
>  146:   91 e0           ldi     r25, 0x01       ; 1
>  148:   91 83           std     Z+1, r25        ; 0x01
>  14a:   80 83           st      Z, r24
>  14c:   cf 01           movw    r24, r30
>  14e:   0e 94 67 00     call    0xce <operator delete(void*)>
>  152:   08 95           ret
> 
> 00000154 <valami::~valami()>:
>  154:   fc 01           movw    r30, r24
>  156:   84 e0           ldi     r24, 0x04       ; 4
>  158:   91 e0           ldi     r25, 0x01       ; 1
>  15a:   91 83           std     Z+1, r25        ; 0x01
>  15c:   80 83           st      Z, r24
>  15e:   08 95           ret
> 
> 00000160 <valami::~valami()>:
>  160:   fc 01           movw    r30, r24
>  162:   84 e0           ldi     r24, 0x04       ; 4
>  164:   91 e0           ldi     r25, 0x01       ; 1
>  166:   91 83           std     Z+1, r25        ; 0x01
>  168:   80 83           st      Z, r24
>  16a:   08 95           ret
> 
>> 2) If they aren't necessary anyway, why don't you just provide your own
>> (empty) implementations of new and delete to avoid the inclusion of
>> whatever runtime library?
> 
> It is a solution, but it just increases the number of unnecessary function 
> calls. The number of constructors/destructors is discussed in an other 
> thread, it would be another optimization step. As far as I understand, the 
> different constructors/destructors are useful for different purposes. If I 
> avoid using the new() and delete() operators, I can save their space. It 
> would be useful to disable the corresponding constructors/destructors in this 
> case.

1) Do you actually need your destructors to be virtual? As you do not use 
the heap you most probably do not destroy polymorphic instances. Hence, 
virtual destructors are not necessary. (There is a switch to suppress the 
annoying warning that newer gcc versions issue in case of a non-virtual 
destructor.)

Especially on the AVR platform virtual function induce a significant 
overhead. You should try to avoid them as far as possible. On the caller 
side, each call to a virtual function requires (compared to an inlined 
function) at least 16 additional byte (text). On the callee side, virtual 
function tables have to be provided (4 byte + 2 byte per entry, data), 
object instances need to carry a pointer to the
virtual function table (2 byte per instance, data), and even if otherwise 
not needed constructors have to be generated to initialize the vtable 
pointer of an instance have to be generated (at least 24 byte per class, text).

2) If they are not virtual, unused variants of the destructor should go 
away by means of function-level linking (on gcc by compiling with 
-ffunction-sections and linking with --gc-sections).


Daniel