Skip to content

perf: Memory optimization for RangeCache#65

Merged
njhill merged 2 commits intomainfrom
rangecache-optimize
Apr 6, 2022
Merged

perf: Memory optimization for RangeCache#65
njhill merged 2 commits intomainfrom
rangecache-optimize

Conversation

@njhill
Copy link
Copy Markdown
Contributor

@njhill njhill commented Apr 6, 2022

Motivation

Currently, RangeCache will implicitly retain a reference to the RangeResponse KeyValue arrays used to initially populate/refresh the cache via the promise held in its startFuture field.

This ref is there only to propagate cancellation to the etcd range request but can take up significant memory once completed if the cache is large.

Note this is mostly the size of the object array itself since the contained objects will usually be referenced from the cache's map. However over time unnecessary references could remain if/when the corresponding KeyValues are deleted. The array's "shallow" footprint might also be non-negligible for very large caches.

Modifications

  • Change the promise used for the start future to hold an explicit reference to the range request future, so that it can be nulled as soon as that other future completes.
  • Remove an incorrect assertion
  • Clean up a weird @Nullable import

Comment thread src/main/java/com/ibm/etcd/client/utils/RangeCache.java Outdated
Comment thread src/main/java/com/ibm/etcd/client/utils/RangeCache.java
@joerunde
Copy link
Copy Markdown

joerunde commented Apr 6, 2022

I guess there's probably no good way to unit test this change?

Except maybe by creating a whole load of RangeCaches and seeing the memory usage not explode?

njhill added 2 commits April 6, 2022 08:47
Motivation

Currently, RangeCache will implicitly retain a reference to the RangeResponse KeyValue arrays used to initially populate/refresh the cache via the promise held in its startFuture field.

This ref is there only to propagate cancellation to the etcd range request but can take up significant memory once completed if the cache is large.

Note this is mostly the size of the object array itself since the contained objects will usually be referenced from the cache's map. However over time unnecessary references could remain if/when the corresponding KeyValues are deleted. The array's "shallow" footprint might also be non-negligible for very large caches.

Modifications

- Change the promise used for the start future to hold an explicit reference to the range request future, so that it can be nulled as soon as that other future completes.
- Remove an incorrect assertion
@njhill njhill force-pushed the rangecache-optimize branch from 1f339eb to f59606a Compare April 6, 2022 16:00
@njhill
Copy link
Copy Markdown
Contributor Author

njhill commented Apr 6, 2022

I guess there's probably no good way to unit test this change?

Not a good way that I can think of, unless we introduce nonfunctional tests to track heap consumption etc.

Copy link
Copy Markdown

@joerunde joerunde left a comment

Choose a reason for hiding this comment

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

leggoo

@njhill njhill merged commit 01bb51b into main Apr 6, 2022
@njhill njhill deleted the rangecache-optimize branch April 6, 2022 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants