Bugzilla – Full Text Bug Listing
| Summary: | [CodeMirror] Performance of the CodeMirror plugin | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Client | Assignee: | Mark Macdonald <mamacdon> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse.felipe, mihai.sucan, simon_kaegi |
| Version: | 0.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Mark Macdonald
Potential problem areas: * Too many styling passes To avoid hanging the UI, the styler does 50ms or 800 lines' worth of styling, then pauses for 75ms. This is too conservative; it takes a long time to finish a large file. * Generating too much garbage Profiling shows anywhere from 13–30% time spent in GC. Some of this is due to plugin-communication overhead, but I may be allocating too much crap while parsing or something. * Data structures When styling a line of code like this: > var fizzbuzz; CodeMirror internally represents the line's style as an array of alternating token and text-fragment: > [ "keyword", "var", null, " ", "variable", "fizzbuzz" ] The Orion-codemirror highlighter instead stores a range of token+line indices, and no text: > [ [0, 3, "keyword"], [4, 12, "variable"] ] Perhaps the extra level of arrays here is increasing pressure on the VM and making it slower??? I did some closer investigation. The orion-codemirror highlighter is on par with CodeMirror's when it comes to parsing an entire file from scratch. The main difference is perceived speed: CodeMirror feels much faster because it works smarter. When running its highlight job, it gives priority to the lines in the editor viewport. Now if you open and immediately jump to the end of a large file, the highlighter hasn't had a chance to parse the lines [0 .. viewportTop-1] which are required to get the correct context for parsing the viewport lines. But in that the case, it cheats by telling the parser to parse as if viewportTop were the start of the file. This quickly yields a rough styling which is not always correct, but works pretty well in practice. After some time, the highlighter finishes the entire file, and the rough styling is replaced with the correct one. I should be able to do something similar by exposing some info about the editor scroll position to the plugin so I can take it into account. (In reply to comment #2) > I should be able to do something similar by exposing some info about the editor > scroll position to the plugin so I can take it into account. See also Bug 363387 #comment2: https://bugs.eclipse.org/bugs/show_bug.cgi?id=363387#c2 Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |