On 18/11/2015 06:10, Arno Brinkman wrote: > Hi Adriano, > >> Arno, can you please verify now? >> It should still reset the array, but much less than before. > Yes!, this makes a big difference, for my sample the speed difference > between FB2.5 and FB3.0 now dropped from 125x to 3x slower for "prepare > time". > > I've been looking at the code to, but what makes me wonder is what causes > the list to be invalidated? According to your "workaround" something is > added in the front. Is this done by parse.cpp ?
It's added in the front in COALESCE, since it uses a (value, value_list) and value is added in front. No optimization is done in this case. It rebuild the children nodes. The optimization now is done because the items capacity increases exponentially (by the Array algorithm), and we can preserve the children when it does not realloc. > Beside all this, i got the feeling that it is unneeded to always make a copy > of all nodes in items to jrdChild and dsqlChild. It's unneeded only if default processing is rewritten for the value list class. Most of nodes was converted to the new code trying to preserve the logic. That one was nod_list with its nod_count. > Next to it, it is very easy to mess around directly with ValueListNode.items > cause it's public? > Yes. Adriano ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
