On 04/03/14 21:25, Dimitry Sibiryakov wrote: > 03.04.2014 18:52, Dmitry Yemanov wrote: > > You destroy those buffer via AutoPtr when they get out of scope. > > Instead, you could release those buffers for reuse at the end of the > > same scope. > > I.e. duplicate code from memory pool in jrd_tra, except may be > those couple of atomic > ops mentioned by Alex. I don't see a reason for it: working with undo > data buffers is not > a frequent operation. IMHO, clean code is better than several saved > CPU ticks.
In yvalve you were saying absolutely contrary things - to save 2 atomic ops you were going to delay deallocation of objects in providers and providers themself. Here you try to add a lot more of them. And remember - undo is one of time-critical places in engine, it's not an yvalve. > 03.04.2014 18:44, Alex Peshkoff wrote: >> We still do not have no-lock pools (and in MT system I treat them rather >> dangerous). >> I.e. any allocation/deallocation in a pool requires some atomic ops. > Isn't pool created with 'shared' flag == false a no-lock one?.. > No, it is not. May be sometimes in the future - but definitely not in fb3.0. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel