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.
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.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
