JDK-8101497 : Consider possibility to reduce TableView/TableRow footprint
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: fx2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-07-12
  • Updated: 2015-06-16
  • Resolved: 2011-07-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
fx2.0Fixed
Related Reports
Relates :  
JDK-8101389 - Make Default Cell skins extend Labeled Skin so that we can reduce node count
Description
NodeMemory.TableViews performance test run with enabled rendering and 64mb of heap able to create only 28 tables.
Each table is pretty small, 5 columns and 10 rows. The data type is simple class with 5 String fields
(similar to Person). 

How to run the test:
> cd tests/performance/NodeMemory
> ant
> java -Xmx64m -cp "rt/lib/jfxrt.jar;NodeMemory.jar" nodememory.TableViewsTest -render true -allocCnt 1 

add "-sleep true" in case you want to pause the process after free memory limit is reached.



It seems to be the main cause is actually related to TableRow objects and associated with them objects.

I did more experiments and in particular run TableView test
(which creates one TableView with a lot of data) with big Scene height equal to 9600.
If test is run with 24mb then it fails by reaching free memory threshold on first iteration after
adding just one row of data.
The reason is because in this case we create 400 TableRow objects
(comparing to 25 in case of Scene height equal 600).
This leads to 2000 of TableCellSkin and other table cell related objects.

Note that overall number of TableRow objects in this test is the same as in the test where
we are trying to create new TableView object on each iteration.
So, the reason why we are able to create only small number of TableView objects is the same
as for this artificial test.

The results of running TableViews (creates tables of size 5x10) test for different heap sizes are:
  -Xmx64m   28 tables
  -Xmx96m   42 tables
 -Xmx128m   57 tables
 -Xmx256m  116 tables
Comments
Verified based on Aurora results: http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2
03-09-2011
Actually the test which tests footprint of TableView/TableRow is NodeMemory.TableView, not NodeMemory.TableViews. NodeMemory.TableViews of course also test, but it is more related to TableView/TableColumn footprint. I can confirm that RT-15047 changes improved footprint of TableView/TableRow 9%. Here are the results of NodeMemory.TableView test: b2501: 892,000 objects b2502: 976,000 objects The link to Aurora results: http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2-graphics-scrum&parameters=%5Bshownbenchmarks%5D%28benchmarkresults.name+%3D+%27NodeMemory.Button.objects_count%27%29OR%28benchmarkresults.name+%3D+%27NodeMemory.Rectangle.objects_count%27%29OR%28benchmarkresults.name+%3D+%27NodeMemory.TableView.objects_count%27%29OR%28benchmarkresults.name+%3D+%27NodeMemory.TableViews.objects_count%27%29OR%28benchmarkresults.name+%3D+%27NodeMemory.TreeItem.objects_count%27%29OR%28benchmarkresults.name+%3D+%27NodeMemory.TreeView.objects_count%27%29%5Brefrelease%5D2.0%5Brefbuild%5D%3D+%272501%27%5Brefjdkrelease%5D1.6.0_23%5Brelease%5D%28pr.product.productRelease+IS+NOT+NULL%29%5Bbuild%5D%28pr.product.build+%3D+%272501%27%29OR%28pr.product.build+%3D+%272502%27%29%5Bjdkrelease%5D%28jdk.product.productRelease+IS+NOT+NULL%29&splitting=%5BX+axis%5DfxConf%2C+metricName%5BComplement%5Dbenchmark%2C+jdkBuild%2C+jdk%5BY+axis%5DbenchmarkName%2C+benchmarkConf%2C+fxRelease%2C+fxBuild%5BZ+axis%5Dos%2C+hwclass%2C+jdkRelease%2C+benchmarkSuite&reference=%5BOthers%5DfxRelease%2C+fxBuild%2C+jdkRelease%2C+jdkBuild%2C+jdk%2C+benchmarkSuite%2C+benchmarkName%2C+metricName%5BReference+Set%5Dbenchmark%2C+os%2C+benchmarkConf%2C+fxConf%2C+hwclass&mixReference=false&flags=&significance=empty&hideDataConfiguration=false&calculateSummary=false&showSummaryExpanded=false&showSummaryContents=true&showComplementAttributes=false&compactTables=true&viewStyle=chessboard&filter= There are no improvements in NodeMemory.TableViews, I will file new bug/optimization for this.
27-07-2011
This should now be considered resolved thanks to the work done in RT-15047.
22-07-2011
It might even be the case that this issue is duplicated/resolved by RT-15047. I'll leave it open for now, pending analysis of the results of RT-15047, which have already been applied to the UIPerf repo.
19-07-2011
RT-15047 is a good step in improving this - it will take the number of nodes in a TableCell from 5 to 3 in the typical text-only use case.
19-07-2011
Would it be possible to get any further analysis into this? Is the TableRow taking more memory than one would expect (it does hold on to TableCell references, but it shouldn't be excessive). I'm guessing the TableRow is only heavy because it contains TableCell, and perhaps TableCell is only heavy because of the TableCellSkin - would this be accurate? Also, I note that in the email you sent about this that there was vastly more Labels being created than TableCells - did you have any theory about this? Also, we're doing some work in this area: refer to RT-15047 for more information. Thanks for your help!
14-07-2011