[Mesa-dev] [RFC PATCH 4/5] ralloc: Make the C++ macros arrange for class destructors to be called.

[Francisco Jerez]

Eric Anholt <eric at anholt.net> writes:

>[...]
> I've used this many times to show overhead in compiling, I didn't see
> any reason things would be different this time.
>
> Of course, this time I happened to run the wrong version of the script,
> which wasn't successfully compiling.  Updated numbers:
>
> x 4636      0.029608      0.057734       0.04657   0.044289073  0.0049689317
> + 4636      0.029798      0.057689      0.046927   0.044643953  0.0049795278
> Difference at 95.0% confidence
> 	0.00035488 +/- 0.0002025
> 	0.801281% +/- 0.457224%
> 	(Student's t, pooled s = 0.00497423)
>
> So, yeah, there's a bit of a loss here, much more than I expected.

Hi Eric, thank you for taking the time to test this.

I can see several possibilities here.  One might be using a common base
class for ralloc-able objects, as Ken suggested in passing.  If the base
class already has a virtual destructor it would avoid the need of having
an intermediate destruction callback executed by ralloc, probably
halving the amount of indirect function calls and hopefully reducing
that difference below your confidence margin.

I also find this solution to be more elegant than using macros to make a
class inherit functionality.

Another possibility would be to make the destructor of ir_instruction
non-virtual.  It seems that the only reason it's virtual right now is to
avoid a (usually reasonable) compiler warning in several places when
subclasses of ir_instruction are deleted.  A different way to avoid it
would be to mark ir_instruction subclasses as "final", which would tell
the compiler that none of them have any subclasses themselves and it's
safe to delete them directly:

| class ir_loop final : public ir_instruction {
|    ~ir_loop(); // Non-virtual
|    // ...
| };
| 
| void foo() {
|    delete new ir_loop(); // Doesn't cause a warning.
| }
| 
| class ir_loop_override : public ir_loop {}; // Causes a compiler error.

Note that the "final" keyword is a C++11 language feature, but it's well
supported by both gcc and clang, and it seems to be supported by VC10 as
well.  This solution has the disadvantage that if any of the
ir_instruction subclasses ever actually needs a non-trivial destructor
it will cause a leak.  The first solution seems like a better
alternative to me.

What do you think?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130922/9afe7db5/attachment.pgp>