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

Eric Anholt eric at anholt.net
Sat Sep 21 09:41:42 PDT 2013


Ian Romanick <idr at freedesktop.org> writes:

> Premature "send" strikes again...
>
> On 09/19/2013 05:26 PM, Ian Romanick wrote:
>> On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
>>> Previously, almost all classes didn't actually call their destructors,
>>> which is non-intuitive for C++ code.  Setting them up to be called was
>>> somewhat of a pain, since it required defining a helper function.
>>>
>>> With the new macros, we can easily encapsulate this complexity, making
>>> destructors just happen automatically.
>>>
>>> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
>>> ---
>>>  src/glsl/ralloc.h | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/src/glsl/ralloc.h b/src/glsl/ralloc.h
>>> index 799d3a9..82a3daa 100644
>>> --- a/src/glsl/ralloc.h
>>> +++ b/src/glsl/ralloc.h
>>> @@ -405,15 +405,23 @@ bool ralloc_vasprintf_append(char **str, const char *fmt, va_list args);
>>>  #endif
>>>  
>>>  #define _RALLOC_OPS(ALLOC, TYPE)                                         \
>>> +private:                                                                 \
>>> +   static void _ralloc_##TYPE##_destructor_callback(void *p)             \
>>> +   {                                                                     \
>>> +      reinterpret_cast<TYPE *>(p)->~TYPE();                              \
>>> +   }                                                                     \
>>> +public:                                                                  \
>>>     static void* operator new(size_t size, void *mem_ctx)                 \
>>>     {                                                                     \
>>>        void *p = ALLOC(mem_ctx, size);                                    \
>>>        assert(p != NULL);                                                 \
>>> +      ralloc_set_destructor(p, _ralloc_##TYPE##_destructor_callback);    \
>
> All of the IR objects share the ir_instruction destructor:
>
>    virtual ~ir_instruction()
>    {
>    }
>
> Doing this universally will add two indirect function calls when every
> object is released.  I wish we had a compiler benchmark so that we could
> know whether this is going to hurt app start up time on apps with lots
> of large shaders. :(

You can test this easily, thanks to shader_runner, "time", and
shader-db.

For a large l4d2 shader:
    N           Min           Max        Median           Avg        Stddev
x 1088      0.012401      0.024984      0.017926   0.017903518  0.0018709739
+ 1088      0.012483      0.028997      0.017919   0.017883756  0.0019610448
No difference proven at 95.0% confidence
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130921/c8ce2476/attachment.pgp>


More information about the mesa-dev mailing list