On Tue, 18 Oct 2022 17:47:38 GMT, Michael Strauß <mstra...@openjdk.org> wrote:

>> I'd respectfully disagree: in a large application, there might be hundreds 
>> (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property 
>> (2%), so it's a waste of RAM.  One may think it's only 8Kb on a 64 bit 
>> machine, but it does add up quickly.  Even the access pattern is basically 
>> 'get it once to establish the fluent pipeline', with no more calls to the 
>> Node accessor (unlike MiscProperties constituents, some of which get 
>> accessed rather frequently).
>
>> I'd respectfully disagree: in a large application, there might be hundreds 
>> (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property 
>> (2%), so it's a waste of RAM. One may think it's only 8Kb on a 64 bit 
>> machine, but it does add up quickly. Even the access pattern is basically 
>> 'get it once to establish the fluent pipeline', with no more calls to the 
>> Node accessor (unlike MiscProperties constituents, some of which get 
>> accessed rather frequently).
> 
> I understand your point, but I don't think that this is sufficient reason to 
> introduce a new way of storing property instances in an ad-hoc manner. If 
> memory consumption is a concern, I would rather analyze the issue in a 
> separate enhancement proposal, think it through in terms of API, and then 
> transition all relevant property instances to the new storage mechanism. Part 
> of that proposal should also be an evaluation of the trade-offs between 
> memory consumption and performance in terms of cache locality and lookup 
> speed.

`getProperties()` isn't the place for this. After looking at the grouping of 
properties, there might be merit to reevaluate the distribution of properties 
into their helper classes in the case that a single use of a common property 
will create many other unused ones.

As for RAM usage, Hotspot can compress pointers on a 64bit machine. I don't 
think that the change in memory here will be more significant than in other 
areas in `Node` that can be addressed.

-------------

PR: https://git.openjdk.org/jfx/pull/830

Reply via email to