thomasmueller commented on code in PR #1689:
URL: https://github.com/apache/jackrabbit-oak/pull/1689#discussion_r1746588145
##########
oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/flatfile/pipelined/SortKey.java:
##########
@@ -59,9 +59,10 @@ public static String[] genSortKeyPathElements(String path) {
// Interning these strings should provide a big reduction in
memory usage.
// It is not worth to intern all levels because at lower levels
the names are more likely to be less diverse,
// often even unique, so interning them would fill up the interned
string hashtable with useless entries.
- if ((i < 3 || part.length() == 1 || part.startsWith("jcr:") ||
COMMON_PATH_WORDS.contains(part)) &&
- INTERN_CACHE.size() < MAX_INTERN_CACHE && part.length() <
MAX_INTERNED_STRING_LENGTH) {
- pathElements[i] = INTERN_CACHE.computeIfAbsent(part,
String::intern);
+ if ((i < 3 || part.length() == 1 || part.startsWith("jcr:") ||
COMMON_PATH_WORDS.contains(part)) && part.length() <
MAX_INTERNED_STRING_LENGTH) {
+ pathElements[i] = INTERN_CACHE.size() < MAX_INTERN_CACHE ?
Review Comment:
OK so we want to threat it as read-only once it is full... Yes that makes
sense. But existing entries that are not popular are not replaced still... So
if the "wrong" entries appear early on, then the cache is not effective.
I would check if a simple one-way set-associative (direct-mapped) cache,
backed by an array, isn't more efficient...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
