You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suggest the last segment in the pool is kept and not freed when empty. Since the segment will only be allocated when the user actually first allocates something, this will not result in useless RAM usage, and will make sure that the future allocations are faster in an allocate-free code scenario. Otherwise you have to specify m_never_free, which is a bit harsh: we'd like to keep the heaps under control and optimize the performance.
void free(block_type const& b)
{
b.m_segment->free(b);
if (!m_never_free && b.m_segment->is_empty())
{
std::lock_guard<std::mutex> lock(m_mutex);
// THIS IS THE CHANGE
if (b.m_segment->is_empty() && m_segments.size()>1) m_segments.erase(b.m_segment);
}
}
The text was updated successfully, but these errors were encountered:
I think that's a good idea - we can even make this configurable later, but for now, i think the default of having one segment always like you suggest is good.
I suggest the last segment in the pool is kept and not freed when empty. Since the segment will only be allocated when the user actually first allocates something, this will not result in useless RAM usage, and will make sure that the future allocations are faster in an
allocate-free
code scenario. Otherwise you have to specifym_never_free
, which is a bit harsh: we'd like to keep the heaps under control and optimize the performance.The text was updated successfully, but these errors were encountered: