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.
[release32 RC4] Auto Comment: scrolling the list of bad members (and moving selection) is deathly slow. Open Auto Comment on several large source files at once, to get say a hundred or two hundred members; position the selection at the top; then hold down Down arrow for a few seconds. The IDE will spend a couple minutes doing nothing but trying to scroll through this list, hardly painting anything else. Taking some random thread dumps while this was happening, I found that AutoCommentListCellRenderer.getListCellRendererComponent is horribly slow (involved in every dump). Typical things it was doing when the stack trace occurred: creating a new JLabel; calling JPanel.removeAll() (according to source comment, prevents a memory leak - well it is also very slow apparently); JComponent.getPreferredSize; AutoCommenter.Element.getName(). Looking at the code, it seems clear that all of this work is wasted. All that is shown per cell is two icons, and one small string. AutoCommenter.Element should cache its name instead of recomputing it each time; and for the icons, there are only a small number, and Utilities.mergeImage could easily be used to merge together combinations in advance (or on demand; mergeImage does its own caching, so a call should typically be fast). Then the default, efficient cell renderer could be used, a single reused JLabel, and no JPanel with BorderLayout etc.
Target milestone -> 3.3
I've tried it using Utilities.mergeImages() and it is a lot faster now. What still bothers me is that mergeImages operate on images (two images as input, one as output) and I need to work with Icons (two ImageIcons as input, any Icon as output). I was using new ImageIcon( mergeImages( ico1.getImage(), ico2.getImage, 18, 0 ) ) and I don't like the new ImageIcon part, espacially when I looked at the ImageIcon( Image ) constructor (It checks the image with ImageTracker if it is already loaded). Couldn't there be something like this that would do caching at Icons level?
OK, rewritten to use one ImageIcon instance, using setImage on it and relying on caching by IconManager. Also changed all the static ImageIcons to be only Images and loaded through Utilities.loadImage instead of ImageIcon(url) Maybe the images could be nonstatic to let them go if not used for longer time and IconManager caches them. But it's about 30KB, is it worth the effort?
Resolved for 3.3.x or earlier, no new info since then -> closing.