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.

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

Reduce memory requirements for RippleState #4080

Closed
wants to merge 7 commits into from

Conversation

seelabs
Copy link
Collaborator

@seelabs seelabs commented Jan 24, 2022

High Level Overview of Change

The motivation for these patches is saving space in RippleState. During path finding many millions of RippleState objects may be created and reducing the size of RippleState can help reduce the memory needed for path finding.

There are two patches. The first patch replaces many uses of shared_ptr<RippleState> with RippleState.

RippleState was normally handled as a shared_ptr. It appears this was done to avoid exceptions. The make function returned a shared_ptr and used a nullptr to signal an error.

While there is runtime overhead in allocating on the heap, this patch is motivated by the space overhead of using a shared_ptr as well as the space overhead of allocating on the heap. The overhead of malloc is typically 8-16 bytes. The overhead of a
shared_ptr is typically around 48 bytes.

The second patch removes the sle that was stored in the RippleState object. Storing the sle means storing some fields twice or keeping references to the data. If the sle is able to be reclaimed, this reduces the memory required to store
the RippleState.

There was also no reason for this class to have a vtable. The virtual destructor was removed and the class was marked final.

Type of Change

  • [ x] Memory Optimization (non-breaking change)

`RippleState` was normally handled as a `shared_ptr`. It appears this was done
to avoid exceptions. The `make` function returned a `shared_ptr` and used a
`nullptr` to signal an error.

There can easily be tens of millions of these objects. While there is runtime
overhead in allocating on the heap, this patch is motivated by the space
overhead of using a `shared_ptr` as well as the space overhead of allocating on
the heap. The overhead of malloc is typically 8-16 bytes. The overhead of a
shared_ptr is typically around 48 bytes.

This patch replaces the return value of the `make` function with an `optional`
and replaces variables that used to hold a `shared_ptr<RippleState>` with a
`RippleState`.
Storing the sle means storing some fields twice or keeping references to the data.
If the sle is able to be reclaimed, this reduces the memory required to store
the RippleState.

There was also no reason for this class to have a vtable. The virtual destructor
was removed and the class was marked final.
src/ripple/app/paths/RippleState.h Outdated Show resolved Hide resolved
src/ripple/app/paths/RippleState.cpp Outdated Show resolved Hide resolved
src/ripple/app/paths/RippleState.h Outdated Show resolved Hide resolved
This information can be retrieved from lowLimit and highLimit instead.
Copy link
Collaborator

@ximinez ximinez left a comment

Choose a reason for hiding this comment

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

I gave this a quick once over, not a deep review, so I could use it in my work. All the changes look clean and sensible to me.

src/ripple/app/paths/RippleState.h Show resolved Hide resolved
src/ripple/app/paths/RippleState.cpp Outdated Show resolved Hide resolved
src/ripple/app/paths/RippleState.h Outdated Show resolved Hide resolved
This has become a more specialized class. The new name signals the less
generalized nature of the class, and helps people making changes to the class
understand the implications.
* Rename PathFindTrustLine.{h,cpp} to TrustLine.{h,cpp}
* Rm old comments
* Rm unused include file
* Additional protection agains instantiating TrustLineBase
@seelabs seelabs added the Passed Passed code review & PR owner thinks it's ready to merge. Perf sign-off may still be required. label Feb 11, 2022
@intelliot
Copy link
Collaborator

@mvadari @mtrippled it would be fascinating to run a couple tests to see what effect these patches have on the max stable capacity of a test network

@seelabs
Copy link
Collaborator Author

seelabs commented Feb 12, 2022

@intelliot This patch only effects path_find. If the benchmark isn't running path_find I wouldn't expect this to have any effect.

@nbougalis
Copy link
Contributor

This was merged into 1.9.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Passed Passed code review & PR owner thinks it's ready to merge. Perf sign-off may still be required.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants