Attempt at reducing GC memory usage when gathering candidates#6449
Attempt at reducing GC memory usage when gathering candidates#6449dlmarion wants to merge 1 commit into
Conversation
This change pushes the Value filtering to the server-side using an iterator instead of using a filter in a Stream, and sets an initial size on the candidate ArrayList to try and reduce resize operations.
| } | ||
| scanner.setRange(range); | ||
| return scanner.stream().filter(entry -> entry.getValue().equals(SkewedKeyValue.NAME)) | ||
| scanner.addScanIterator(new IteratorSetting(25, "gcCandidate", GcCandidateFilter.class)); |
There was a problem hiding this comment.
Are we keeping track of the system iterator priorities being used?
I see the default value of the versioning iterator being set at 20, but that's just a hardcoded value.
Wondering if that initial value of 20 should be refactored into a system constant of DEFAULT_ITERATOR_PRIORITY.
There was a problem hiding this comment.
Are we keeping track of the system iterator priorities being used?
I don't think there is a constant in 2.1, there might be a constant in 4.0. I can look for that.
There was a problem hiding this comment.
I'm not seeing a constant. I see a literal 20 being used in main in IteratorConfigUtil.getInitialTableIteratorSettings
ddanielr
left a comment
ddanielr
left a comment
There was a problem hiding this comment.
Changes make sense. GarbageCollectorIT still passes.
2 participants
This change pushes the Value filtering to the server-side using an iterator instead of using a filter in a Stream, and sets an initial size on the candidate ArrayList to try and reduce resize operations.