JDK-8113318 : Performance of Ensemble KeyEvent sample is very poor
  • Type: Bug
  • Component: javafx
  • Sub-Component: samples
  • Affected Version: fx2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2011-06-03
  • Updated: 2015-06-16
  • Resolved: 2011-06-14
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.0Resolved
Related Reports
Blocks :  
JDK-8100850 - NGText should clip single line text to avoid excessive rendering
Blocks :  
JDK-8090461 - Insertion sort in OpenPisces ScanlineIterator may be very inefficient
Duplicate :  
JDK-8112239 - Pasting long text into TextBox locks the application
Relates :  
JDK-8113884 - Memory leak in VirtualFlow when sorting by a column
Description
Based on forum post here: http://forums.oracle.com/forums/post!reply.jspa?messageID=9633058

In summary, Ensembles KeyEvent sample becomes progressively slower. However, if this is taken out of Ensemble and run as a standalone application, performance is as expected. There must be something going on in Ensemble to slow this down.

I'm attaching a standalone test app that works far faster on my machine than the equivalent code in Ensemble.
Comments
Verified on build 42.
30-08-2011
Fixed in graphics-scrum #2276 with changeset 12654:2c16d392e90e
23-06-2011
I have filed RT-14358 Insertion sort in OpenPisces ScanlineIterator may be very inefficient RT-14356 NGText should clip single line text to avoid excessive rendering to address remaining issues with the original test case.
18-06-2011
@Oleg, please keep me linked in to any issues you file that affect performance of ListView/TreeView and especially TableView. Please add me as a watcher. I already have a TableView performance bug lodged at RT-14045, but unfortunately my attempts at profiling have largely come up empty handed: performance suffers due to CSS and text. I look forward to further analysis you may provide (be it here or in a separate Jira issue).
15-06-2011
With the memory leak fix the number of dirty nodes on every pulse is constant and all activity on the user thread is now reasonable and consumes little time. Yet, rendering time continues to grow (reaching seconds per frame). The leaf node that consumes almost all that time is NGText, which seems to correspond to the duplicate issue. More analysis is required.
15-06-2011
Duplicate of RT-12251.
14-06-2011
Fixed the memory leak mentioned by Oleg: I now clear out VirtualFlow.sheet to prevent this growing endlessly. @Oleg: I'd appreciate any other pointers you may have regarding performance of ListView/TreeView/TableView. In particular, HelloTableView has a performance test tab that shows severe performance degradation. @All: The performance of Ensemble's KeyEvent sample is still slow, although I have a reason for that: it is TextBox - as the number of characters within it grows, the slower the performance becomes. This is already recorded in RT-12251, so I'm going to close this as a duplicate of that issue.
14-06-2011
I also noticed VirtualFlow.sheet is accumulating things the other day, although in my testing (unreleated to this issue) it seemed to only accumulate a very small number of nodes. I will test with the attached application to see if that results in further accumulation than what I noticed. If you think that VirtualFlow.sheet is the culprit, I will dig deeper there and make improvements to ensure it releases cells. If you have further suggestions, I look forward to hearing them. Thanks!
11-06-2011
With JPA I was able to see that rendering time was steadily increasing with every pulse, which indicated that a growing number of dirty nodes was likely to be the cause. I printed out dirty nodes from Scene on every pulse to see what nodes and how many we are going to render. That confirmed the hypothesis and revealed ListViewSkin and ListCellSkin as culprits. One suspicious piece of code is in com.sun.javafx.scene.control.skin.VirtualFlow.java. I can see that Group sheet accumulates child nodes but never releases them. It's responsible for ListViewSkin objects. The number of those objects grows with every pressed key (is that to be expected?). ListCellSkin objects are among the children of ListViewSkin objects, so naturally their number grows as well.
10-06-2011
@Oleg: Very interesting. Are you able to give me any further insight into this, or perhaps a means of identifying the issue in more depth?
10-06-2011
As of build 31, which includes the fix for RT-13749, the problem is still there. It appears that some new Nodes (specifically ListViewSkin and ListCellSkin ones) are never removed from the Scene. Their ever increasing number causes doCSSPass() and, much more noticeable, rendering time to grow.
10-06-2011
@Oleg: I just checked my local repo and had not pushed the changes that fix the ListView performance issue identified above. I've integrated them locally and will push the change shortly once tested. Before downloading another controls-scrum-build to test this, be sure to check the changelog for references to RT-13749. Thanks!
03-06-2011
With the latest controls-scrum build (#445) the performance problem is still there.
03-06-2011
This is correct. I've fixed a number of these performance issues (in particular the accumulation of editingIndexProperty listeners). The fix should be in the latest controls repo already, but I may not have pushed it quite yet. It would be interesting to hear if you can reproduce it in a more recent build (or from the latest repo code).
03-06-2011
I'm able to reproduce the problem with the standalone test on my laptop (using consoleObservableList.clear() rather than consoleObservableList.remove(0)) . The immediate cause of visible slowing down is increasing rendering time which pretty quickly reaches seconds per frame. The CSS pass time in the scene graph also increases with time, though not so dramatically. One symptom is that ListView accumulates editingIndexProperty listeners from ListCell, which are never removed.
03-06-2011