Ian Romanick <[email protected]> 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 <[email protected]> >>> --- >>> 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
pgp5ojOD_bOWB.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
