Community
Participate
Working Groups
Investigate performance improvements for starting up the help viewer. We are launching the browser in another VM (Windows) or launch the system browser, but there could be some optimizations there. Rendering of the help UI should be reasonable fast (precompiled JSP, optimized HTML, etc.)
Investigate browsing of large documents (1-10 meg)
Browsing large documents ~10MB is robust. Document is displayed almost immidiately, and continues loading in the background (shell responds). Same behaviour is when using external browser. Loading document through help server is not noticably slower than openning the file in a browser straight from a file system. The problem appears when a large document ~1MB is a result of search. Javascript hightlighting code appears to freeze the shell for a duration of its run. It takes in the order of 10s/MB to highlight 1 keyword. For example, displaying 1MB document, result of search for "end of file" takes 15s. Displaying 10MB document, result of search for (unquoted) 'end of file' takes forever (did not finish in 5 minutes). Eclipse responds, but closing it, does not close the browser, until highlighting code ends. The browser process needs to be killled to reopen help. Same behavior when an external Internet Explorer is used.
Released the code to limit duration of highlighting code for documents > 50k. In these documents the search keyword highlighting code will terminate after 3 seconds, even if not all terms have yet been higlighted. The new code that checks time is not added to code used for highlighting of shorter documents since the extra code adds decreases highlighting speed by 15%.
Constructing IEBrowserAdapter object, used to launch external viewer with Embeded IE browser takes long (almost 4 seconds with profiling turned on). Its getClasspath method takes most of this time).
Released optimized code to decrease execution time of IEBrowserAdapter.getClasspath from 3.59 to 0.77 seconds. Also cache the command to launch external process, once the command is constructed. As a result of teose optimizations, constructing IEBrowserAdapter now takes 1.0 second (down from 3.96) for the first time, and ~0 for the next.
This looks great. Well done. Any idea how it would be affected by the use of an internal viewer like Mozilla?
Jeff, I do not know what implementation internal browser like Mozilla would use. Likely there would be different completely different issues. The problem was specific to the way we launched window with embeded IE. Opening window with embedded IE took long for two reasons. Because, IE browser window is run as separate JVM process (and SWT application), it takes some time for the other JVM to start and we do not see a way to speed it up. Unfortunately due to modality issues help browser is preferred to be out of process. The other reason it was taking long to start was that we need to calculate the classpath to pass to the new process. Since the code uses classes from help UI, JFace, SWT, and it is not possible to pass a class loader to another process, our code inside Eclipse was obtaining lists of JAR URLs from help ui plugin and all plugins in its require chain. With many requires present in those plugins, we got a list that was almost a thousand URLs, since there were many duplicates. We were collecting and processing all of them before ensuring there is no duplicates. After a fix, a HashSet is used from the start to eliminate duplicates, and no unnecessary processing is done.
Browsing large documents is not slow, but has large memory requirement. The content filters work on a byte[] that hold complete document in the memory for a period of time. This should be changed so filters work on streams and possibly have bounded size buffer in the memory. This needs to be fixed, especially that more than one document can be accessed at a time (on separate threads), and the total memory requirement may be greater than size of any large document alone.
I have redesigned document content filters to direclty filter OutputStream without a need for any buffer.
I played a bit with the generated html code for a book and tried to make it smaller. Here are some numbers: The generated HTML for the Platform Plug-in Developer's Guide is about 98.9K. I performed the following (in this order): - removed the <nobr> tag resulted in a 94.1K file. Note: this tag is only needed in the IE5.0 browser to properly render each topic title on the same line. Newer browsers can use proper CSS support for this. - replaced the image names topic.gif, content_obj.gif and plus.gif by t.gif, c.gif and p.gif and the resulting file was 92.2K - replaced the images/ directory with i/ and the file was reduced to 87.6K - replaced the hidden style attribute for plus.gif (on topic leaves) by class='h' and move the definition in the <style> tag at the beginning resulted in a file of size 82.6K I have not checked in any of these changes, but it looks we can get about 20% reduction in the size of the navigation file when using more cryptic names.
I checked in changes for the first and last steps (eliminated <nobr> and the style definition for hidden image), and also eliminated the title attribute, and set it with javascript.
Fixed
