On 04/02/2026 22:17, Andy Goryachev wrote: > I would like to share the results of a little experiment involving > optimization of storage of Node properties. The basic idea is to > create a compact fast map-like container to hold the rarely > instantiated properties in order to reduce the application memory > footprint. > > The savings are not overwhelming, but not exactly zero. I would > imagine this optimization might be more interesting in any resource > constrained environment such as Android / iOS / RaspberryPi. Please > refer to [0] for the details.
What trade off are you making here? It seems we're trading a small memory gain for more CPU use (extra indirection, walking a list linearly to find the correct property on each use/access VS no indirection, no list walking). Are the resource constrained platforms you named generally memory or CPU constrained? Have you investigated a breakdown of JavaFX memory use, and did the amount of memory used by properties come out on top here? Would the gains you made here become irrelevant or less relevant with Compact Object Headers [https://openjdk.org/jeps/519] > > I encourage you to try it with your application, to see whether you > notice any change in memory consumption and/or performance. Let me > know what you think! I like the idea, but I wonder if there really is much to gain here, and whether those gains will hold up with future Java improvements. I think the property look-up system cannot reasonably be List (FastMap despite its name is a List). Converting this to a map however is likely to require a small object (like Map.Entry) which will further reduce any gains you made here I think. --John > > Cheers, > -andy > > > *References* > > [0] > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md >
