On 02/09/2019 08:22, Alex Peshkoff via Firebird-devel wrote: > On 02.09.2019 13:42, Dimitry Sibiryakov wrote: >> 02.09.2019 12:26, Alex Peshkoff via Firebird-devel wrote: >>> When first pool-enabled classes were added to firebird ~15 years ago >>> allocators were absolutely unable to peresent firebird pools. >> >> Pools were implemented that time because standard memory manager >> was slower. > > Not only for that reason. Delete by pool is very important performance > optimization.
Pools are also used for memory accounting. > >> Had someone compared their performance now? AFAIK Firebird without >> pool can be built by changing of one macro (used for >> valgring-compatible build). >> >>> I doubt basic rules of using them have changed - that can break >>> applications using allocators in _that_ way. But if yes - that would >>> be great. The first problem was object assignment - src allocator >>> was also assigned to target. How is it doing now? >> >> It is up to Allocator now: >> https://en.cppreference.com/w/cpp/named_req/AllocatorAwareContainer >> > > That's great. May be it's really time to use stdlib with allocators. It's the same. As soon someone does not chain everything being allocated or has non-memory resources, finalizers are needed when delete by pool is used. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
