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.
When opening files, Netbeans reads the entire file into memory then applies font attributes across the entire file. This is extremely unefficient and the slowdown is noticable even on JSP files 1000 lines long. What I recommend is: 1) Either improve the current file-opening algorithm, or 2) Load the file incrementally so Netbeans only loads the visible part of the file into memory and loads more as needed. This way we can defer slow opening of files or large memory footprints for unused files. I set this to P2 because performance on Netbeans is becoming alarmingly slow. Adjust the priority if you feel differently. One piece of warning: if you implement choice #2, you better make sure scrolling through the first for the first time won't be noticably slower than it already is..
Hi Gili, I was testing the alternative 2) at times I've created the NB editor but unfortunately I had to give up. The problem was that very soon after the creation of the document the Document.getLength() is called which causes the entire file to be read. Originally I thought I could guess the remaining length from the corresponding file being read but I have faced these problems: 1) Often I only get the Reader into editor so I even do not know the corresponding file. 2) Even if I know the file there can be e.g. UTF-8 encoding which can map 2 bytes to one char so the knowledge of the length of the file does not help. 3) Even for single-byte encodings the swing methods expect to find only "\n" as line separators in the document so if there are "\r" they must be eliminated from the created document (and not counted in the getLength()). So I've given up to use incremental loading. Regarding improvements of the file-opening algorithm: There will be one improvement once we start to use the lexer module. Currently the lexer (called Syntax) is called during the reading of the file (to create the lexer state marks at every 100th character of the document; these marks allow to restart the lexer from the given position). This will be eliminated and the lexer will in fact only be called for the visible portion of the document. The jsp is rather difficult from the lexing point of view because the nesting of the jsp-tags can occur at any place in the content language. However I think that we will be able to address this problem more efficiently in the new lexer module. Regarding the font attributes we only evaluate the maximum height of the line by computing the biggest font that can be created by combining the colorings. During the reading of the file we find out the line with maximum count of characters and measure it visually. We set the initial horizontal scrollbar size according to this information. The problem is that if we find (during painting) that some line is visually even wider we need to call revalidate() on editor component which, in case you drag the scrolling button, can cause jumping to the line begining. But I have a feeling that someone told me that this should no longer be a problem in 1.4. BTW the firstly opened file is always slow because (in order to reduce the startup time) we no longer preload any classes for the editor. Well, I think that except the lexer module I can't do much with the problem. The lexer module will be introduced soon so we don't need to fill in an enhancement. If you don't mind, I would like to close this bug according to the explanation above. Mila
Set target milestone to TBD
As document modifications should be paired with corresponding token modifications in the document events being fired the lazy creation of tokens that I have considered originally is not possible. Instead we need to support a sort of asynchronous loading similar to what is done in JEditorPane.setPage() and the corresponding JEditorPane.PageLoader. The implementation can reuse AbstractDocument.getAsynchronousLoadPriority(). There could be e.g. a asyncLoadComplete document property that would mark when the async loading is finished. The property could be checked by document listeners after each subsequent sub-insert. We need to modify openide/text to support this async loading in CloneableEditorSupport.prepareDocument().
Sorry, regarding Cargo, one of the advantages is that maybe it'll allow Netbeans to ship an integrated Tomcat server but also have a new feature which makes it easy to "wrap" around another preexisting server on the system (which might or might not be Tomcat).
Asynch loading of editors in CloneableEditorSupport is available since 6.1. There are some bugs, like bug 149717, but we shall be in much better shape now, then we were in the past.