Community
Participate
Working Groups
There is swirl around the performance impact of the smart features. We need to do some real benchmarks to understand the cost of these. To that end, we should run a simple scenario with the features all on and with them all off. This should be run on a modest machine (I generally hack on a P3 500). The JDT UI team is better placed to put detail in the scenarios but they should be something like: 1) load an interesting project set (the large Eclipse workspace for example) 2) open several java editors (do the following using code assist etc liberally) 3) switch between them in dirty and clean states 4) do several code mods (cases where the various smart features would kick in) in different files without saving 5) save all 6) do several code mods (cases where the various smart features would kick in) in different files saving before switching editors 7) delete some type required by the types being edited (e..g, its supertype or interface) 8) repeat the above steps Using optimizeit (or your favorite tool) look at the number/size/type of objects created during these various operations. Also time them (may have to instrument the code). The results should be compared on an apples for apples basis.
Adam, can you please investigate. May be you have to carbon Claude for this.
will investigate for M4 and treat this as a bucket
removing milestone - this is not a bug report really.
not a bug report - a reminder most of bug reports i filed in the last couple of days cover these scenarios ok to resolve as REMIND?
The intention of this report was literally to do the benchmarks suggested. It was not intended as a catch all meta bug report. Ultimately, we need to know concretely the cost of these features in terms of time and space. Most eclipse developers run on ultra cool/fast machines with gobs of RAM. Many users are stuck on 2-3 year old machines (e.g., P3 500 or so) with limited RAM. It is vital that those users be supported in a first class way.
here's a shortened list of bug reports i filed about these issues (the list you gave is so broad that maybe too many things qualify) bug 20038 deleting fields is slow on large files [ccp] bug 27072 [Action sets] SelectionListenerAction allocates 2 * ArrayList(10) everytime selection changes bug 27075 JavaOutlinePage.LexicalSortingAction could maybe lazily initialize fSorter bug 27105 JavaElementAdapterFactory.getResource should probably not call getCorresponding resource bug 27108 [JFace] ListenerList should default its size to 1 bug 27110 ListenerList should default its size to 1 bug 27114 something leaks StyleRanges and Lines bug 27304 [View Mgmt] debug views eagerly created on first switch to debug bug 27308 [startup] restoring editor history takes 10% of startup time bug 27311 debug actions too interested in selection changes in package explorer bug 27318 single cut/undo allocates 2Mb of garbage of char[] bug 27321 hovering allocates megabytes in seconds and some already resolved bug 26997 StyledTextRenderer: creates too many Strings bug 27002 Scanner allocates new ArrayList(10) everytime it's created bug 27073 [Key Bindings] WWinKeyBindingService allocates ca. 7-8K of objects on each selection change in the workbench bug 27076 [Key Bindings] any reason why TreeMap was used in org.eclipse.ui.internal.actions.keybindings.Node? bug 27097 IJavaElement.exists probably too expensive to call on selection changes bug 27264 opening/closing java files in presence of hiearchical package explorer is slow bug 27293 [runtime] Path.computeSegments - garbage created bug 27312 CopyResourceToClipboard action allocates too much garbage
i entered some 89 bug reports for performance issues between M3 and M4 many of them were about exactly these issues closing this
But did you establish the actual cost of the smart features. This bug report was not saying that these features are slow/big/... but rather that there is no clear understanding of the cost they are incurring. This is especially relevant because for many of them there is no (clear) way to turn them off. What I am suggesting is that the JDT team figure out how to turn them off and then run tests/benchmarks with them on and off and see the difference in speed/space for various scenarios.
The intent is that all smart features can be disabled on the Java preferences page. Please be more specific with regard to: "there is no (clear) way to turn them off." For which smartness feature couldn't you find a clear way to turn them off? Given that this is already a monster bug I'd like to close this one and open a new one. We have covered the smartness features in our scenarios (and fixed several issues), so I agree with Adam that this bug is OK to close.
I don't mean to be a pain but this bug report is about performance numbers for the smart features. A resolution to this is one of a) here are the numbers or b) we aren't going to generate any numbers. So if the latter is the case then close it and say you won't do it (probably needs some justification given our current performance kick). If the former is the case, put in the numbers.
smartness features were covered in performance pass - numbers are some of the ca. 90 reports i entered then i'm still hesitating if this is a bug report (i.e. does not report any defect really) please reopen if you think that there's a scenario that we did not cover
