From: Michael Widenius Date: March 5 2009 7:43pm Subject: Re: [Drizzle-discuss] Removing Array custom vector allocation for semi-join subqueries List-Archive: http://lists.mysql.com/internals/36349 Message-Id: <18864.11127.783822.743814@narttu.askmonty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! >> For certain objects, memroot is a much better way to do it than with >> C++ deallocators: >> >> - Uses less memory overhead for objects >> - Less mutex, as you mainly do one free per query and >> - Much faster malloc; Mallocs are done in bigger chunks and for many >> queries you can avoid do any mallocs at all (when the base memory you >> have is big enough) >> >> memroot is of course not useful for objects that changes size or has a >> short life time, but it wasn't designed for these. >> >> Jim> Monty, aside from minor issues like breaking C++ language semantics, Jim> this is extremely dangerous from an engineering point of view. The Jim> problem is this: If an object is properly deleted, its destructor is Jim> called. If it is deleted with the pool, the destructor isn't called, Jim> but the memory deleted anyway. Valgrind isn't going to notice a Jim> problem, but the failure to call the destructor may leave memory subtly Jim> corrupted. To work, it requires that the code and/or engineers track Jim> which objects need to be explicitly deleted. Unreliability comes from Jim> this sort of problem where an engineer has to understand the entire Jim> system to make a successful local change. I assume you know that we have taken this into account for C++ objects that are put into the memory root, like items. For these all destructor's are called before the memory is deallocated. Jim> If you're concerned about memory allocation/deallocation performance, Jim> use a thread based memory allocator that eliminates the mutex. You get Jim> the performance you want leaving C++ semantics intact. It will lead to Jim> cleaner encapsulation, faster code, and a lower induced bug rate. You can't get it faster than memroot and not much cleaner either... Bug rate is in the eyes of the coder; A imaginative coder can make mistakes or break anything and for this the c++ destructors offers no protection. As far as I have seen in the past, using memroot give you faster code, and lower bug rate than when using normal C++ code. Regards, Monty