This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Provide results of performace 'sanity' tests to prevent regression of performance from the current winsys; mainly for things like startup time, reading/storing the config, d&d, switching windows/groups, memory consumption etc).
Created attachment 12031 [details] initial startup measurements
Why the ws2merge? Is this needed before merge? I will not have time to do it without dropping some UI enhancements for sure.
Question for Pavel Buzek: What if regressions are found? Must they be fixed before closing this TCR? Reason I'm asking is that perf fixes are usually time consuming task, they should be inserted into our schedule, some planned UI work abandoned or merge date slipped.
This TCR does not define perf. criteria nor does it say what to do when there are regressions found. Its purpose is just to make sure the performance issues are known and covered - the concrete decisions and solutions about the issues are up to you. You should not close this issue untill all the necessary measuring is done and issues filed, but need not wait for fixing the issues I think.
50% regression in startup time (37055) is pretty big. We filed the TCR to make sure you test it and evaluate the results. Are you sure that you can fix the performace later? Is not it dependent on the architecture? If you are not sure I would suggest doing performance work before merge. What is the opinion of Jarda and Jesse?
Pavel, me, Jesse and any other reviewer should judge just a technical quality of the architecture and not be distracted by anything else (for example that users would love the new window system). And from technical point of view it is clear, this issue is big and until it is fixed, we cannot release. Whether to merge or not depends on the confidence of the team to be able to solve the issue in time. Personally, I would wait at least until it is investigated and understood where the time is actually being spend and a "get well" plan is known.
Answers: No I don't know if we can fix regression later, and I don't know if it affects architecture. My knowledge about startup procedure of new winsys is limited, so I can't answer these questions. Passing to Peter for further examination. Radim could you help Peter with profiling? (only if Peter would need it, of course).
OK, results after discussion with Peter: Based on the test results and created issues, we identified two places where performance could be improved, details are in 37055 for startup and 36985 for document opening / DnD operations. Both of these changes don't affect overall concept, perhaps we can fix them even before the merge, but surely into FCS. So tests done, issues created, perf bottlenecks identified - I'm closing as fixed.
verified