msfroh commented on issue #15191: URL: https://github.com/apache/lucene/issues/15191#issuecomment-3304412161
> The costs of polymorphism may outweigh the cost of memory savings here. Hard to tell without trying. I'm also concerned about this one. My knowledge of Java inlining mostly comes from https://blunders.io/posts/es-benchmark-4-inlining, but I get the impression that if there are 1 or 2 implementations, then things will eventually get inlined. Making the class `sealed` with exactly two implementations is important to make sure we don't end up hitting the megamorphic case. Of course, the bimorphic inlining is probably still a little more expensive than accessing a public field. (I can't imagine that it would ever be cheaper.) > This class should only be used as a pointer (BytesREF) and not as a string class. Why would you have many many pointers where such a savings would help so much? Yeah... that's where I'm concerned that it may be a waste of time. Within Lucene, I think BytesRefs fall into two buckets: 1. BytesRefs that hold or wrap long-lived resizeable, reused buffers. For these, the offset and length are key to reuse (and we pay the 8 bytes anyway). 2. Really short-lived BytesRefs created from user input. Examples are in `Term`, `KeywordField`, the various `pack` methods in the `*Point` classes. The first bucket needs to spend the extra 8 bytes anyway, and there aren't a lot of them. The second bucket is where we could save some bytes (since we're allocating a bunch of variable-length wrappers for fixed byte arrays), but the objects are all so short-lived that it might not matter. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
