Tor Didriksen a écrit, Le 16.05.2011 14:19:
> On 2011-05-16 14:16, Guilhem Bichot wrote:
>> Tor Didriksen a écrit, Le 16.05.2011 13:48:
>>> #At file:///export/home/didrik/repo/trunk-dynarray/ based on
>>> revid:andrei.elkin@stripped
>>>
>>> 3088 Tor Didriksen 2011-05-16
>>> Bug#12552221 - MEMORY LEAK IN UPDATE_REF_AND_KEYS
>>> Allocate array in memroot rather than heap.
>>> Fixes the leak, and also yields a 1-2% performance gain with
>>> sysbench if you have lots of cpus/threads.
>>> @ sql/mem_root_array.h
>>> A typesafe replacement for DYNAMIC_ARRAY.
>>> We use MEM_ROOT for allocating storage, rather than the C++
>>> heap.
>>> The interface is chosen to be similar to std::vector.
>>
>> This existing template in sql_array.h looks to have similarities with
>> the above new one:
>>
>> /*
>> Array of pointers to Elem that uses memory from MEM_ROOT
>>
>> MEM_ROOT has no realloc() so this is supposed to be used for cases when
>> reallocations are rare.
>> */
>>
>> template <class Elem> class Array
>> {
>> enum {alloc_increment = 16};
>> Elem **buffer;
>> uint n_elements, max_element;
>> public:
>> Array(MEM_ROOT *mem_root, uint prealloc=16)
>> ...
>>
>> Maybe you can reuse/modify it...
>> If not, maybe it can be deleted and your new stuff can be used
>> instead... Having two "dynamically growing arrays allocating in
>> MEM_ROOT" sounds like redundancy...?
>
> Yes, I know.
> But Array works on pointers only, rather than objects.
> I am all for removing it, and using my new class instead.
So, the only usage of Array I found is in sql_select.h:
Array<Item_exists_subselect> sj_subselects;
which could be translated to using your new class with "object type" ==
"pointer to Item_exists_subselect" ...?
