Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

optimize memory allocation of changesets with many small strings #5614

Merged
merged 2 commits into from
Jun 24, 2022
Merged

optimize memory allocation of changesets with many small strings #5614

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ade8cb4
optimize memory allocation of changesets with many small strings
ironage Jun 22, 2022
bfc9de9
let strings manage their own capacity past the first 1024
ironage Jun 23, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@
### Fixed
* <How do the end-user experience this issue? what was the impact?> ([#????](https://github.com/realm/realm-core/issues/????), since v?.?.?)
* Fix a UBSan failure when mapping encrypted pages.
* Improved performance of sync clients during integration of changesets with many small strings (totalling > 1024 bytes per changeset) on iOS 14, and devices which have restrictive or fragmented memory. ([#5614](https://github.com/realm/realm-core/issues/5614))

### Breaking changes
* None.
Expand Down
8 changes: 7 additions & 1 deletion src/realm/sync/changeset.hpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -539,7 +539,13 @@ inline StringData Changeset::string_data() const noexcept

inline StringBufferRange Changeset::append_string(StringData string)
{
m_string_buffer->reserve(1024); // we expect more strings
// small string optimization; we expect more strings, but constantly requesting many small allocation increases
// to the string buffer can become a performance bottleneck in highly fragmented or low memory devices
constexpr size_t small_string_buffer_size = 1024;
if (m_string_buffer->capacity() - m_string_buffer->size() < string.size() &&
string.size() < small_string_buffer_size) {
m_string_buffer->reserve(m_string_buffer->capacity() + small_string_buffer_size);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to instead use exponential growth with a minimum size? Growing by 1024 bytes each time makes the constant factor a lot better but still leaves it quadratic time.

Suggested change
if (m_string_buffer->capacity() - m_string_buffer->size() < string.size() &&
string.size() < small_string_buffer_size) {
m_string_buffer->reserve(m_string_buffer->capacity() + small_string_buffer_size);
}
if (m_string_buffer->capacity() - m_string_buffer->size() < string.size()) {
m_string_buffer->reserve(std::max(std::max(small_string_buffer_size, m_string_buffer->capacity() * 2), m_string_buffer->size() + string.size()));
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to suggest this exact change, but then I thought "wait don't vectors/strings amortize their growth?" At least on libc++ strings double in size when they exceed their capacity until you reach a capacity that's half the size of the maximum capacity of the string. Then I read the cppreference page for reserve() and realized we're probably shooting ourselves in the foot here. https://en.cppreference.com/w/cpp/string/basic_string/reserve. Until c++20:

  • If new_cap is less than the current capacity(), this is a non-binding shrink request.
  • If new_cap is less than the current size(), this is a non-binding shrink-to-fit request equivalent to shrink_to_fit() (since C++11).

I suspect that what's going on here is that we reserve 1024, and then for every additional string that we append past the first 1024 bytes, we effectively shrink_to_fit the string. If we change this to only call reserve if the capacity is less than 1024, do you still see the slowdown?

Btw, this behavior goes away in C++20.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, I wouldn't have guessed that reserve() would do a shrink_to_fit(). I guess I'm glad c++20 fixes that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, good analysis. I will change this to let the string implementation do its own capacity management and ask Eric to see if it is more effective.

size_t offset = m_string_buffer->size();
m_string_buffer->append(string.data(), string.size());
return StringBufferRange{uint32_t(offset), uint32_t(string.size())};
Expand Down