search

DevShiftTeam / AppShift-MemoryPool

A very fast cross-platform memory pool mechanism for C++ built using a data-oriented approach (3 to 24 times faster than regular new or delete, depending on operating system & compiler)
Apache License 2.0
214 stars 25 forks source link

Benchmark code comparing the custom String class with std::string is not an apples-to-apples comparison #8

Closed azureskydiver closed 3 years ago

azureskydiver commented 3 years ago

Most C++ implementations of std::string will allocate a new block when appending a string (unless the implementation is specifically tuned to always allocate extra space after a string assignment); and then the data from the old block is copied to the new block, and the old block is freed. The memory pool implementation doesn't have to allocate a new block. It just extends the current block and so it gains the speed advantage.

It would be a fairer benchmark if the String class were templated and it took an Allocator where the allocator could either be the standard C++ allocator, or the MemoryPool allocator. That way it can be shown that the same operations are being performed, but MemoryPool is actually faster.

LessComplexity commented 3 years ago

Interesting Idea. I think I will just create another implementation of String which uses the regular new & delete and compare it to the implementation with the current string class, what do you say?

azureskydiver commented 3 years ago

You can't mix in calling the standard C realloc() to reallocate a memory block that has been allocated using new. Yes, it may work with some C/C++ runtime implementations, but there is no guarantee that it always will, specially if the user override the global new with their own implementation.

LessComplexity commented 3 years ago

Thanks again for your comment, I change the realloc() to a new then memcpy and then delete