Community
Participate
Working Groups
Build Identifier: Build id: 20110218-0911 I have to wait 30-60 seconds after each keystroke before I can type another keystroke. CPU utilization topping out above 50% all the while. Heck, Eclipse is at 30-40% utilization on a 2CPU core when doing nothing. Reproducible: Always Steps to Reproduce: 1. Open an HTML file. 2. Try to type anything. 3.
Update: this is not an issue with the HTML editor (Locked) shown under file associations, but with the Web editor, which other than enabling a rendering pane, appears to be no different functionality wise from the "Locked" HTML editor. Which leads to the question: Why is the "Web editor" essentially unusable, where the "HTML editor (Locked)" works without issues?
Beads, I believe that the Web Page Editor (which I assume you mean when you state "Web Editor" is part of Java Server Faces, so I am moving this over to their bucket. I also assume that this was a problem with the Helios SR2 version, due to the build identifier that was given. Have you tried to reproduce this on Indigo (Eclipse 3.7/4.1)?
Some more questions to help us understand the issue: Is this a WTP Dynamic Web Project? Does it have the Java Server Faces facet? Are you adding tags in the source view or are you working the Design page?
(In reply to comment #2) > Beads, I believe that the Web Page Editor (which I assume you mean when you > state "Web Editor" is part of Java Server Faces, so I am moving this over to > their bucket. I also assume that this was a problem with the Helios SR2 > version, due to the build identifier that was given. Have you tried to > reproduce this on Indigo (Eclipse 3.7/4.1)? Installed Indigo the other day. Under Indigo, some documents just fail to open under Web Editor, returning null pointer exceptions. Given that I can't even open half my HTML files using the Web Editor, I haven't attempted to determine if it is still slow when making edits.
(In reply to comment #3) > Some more questions to help us understand the issue: > Is this a WTP Dynamic Web Project? > Does it have the Java Server Faces facet? > Are you adding tags in the source view or are you working the Design page? No, this is trying to edit simple HTML and Javascript. Some pages also have some custom Yaws <erl> tags or else PHP. I'm not coding Java, let alone Java Server Faces (whatever that is). I downloaded this as part of a package called "Web tools", assuming it was for Web editing (per the name), not Java development. I was typing plain text in the source view. Typing the words "Hello, world" would be a lost cause, because the word "Hello" would take 5 minutes to type as it was. Am curious: are there any HTML editors with design panes that don't assume one si programming Java?
I can't reproduce in 3.2.3 (Helios SR2) or 3.3 (Indigo). I've tried HTML and JSP in static web projects, dynamic web projects, and outside of any project. Performance is fine for me. Please attach a zipped workspace, zipped project, or file(s) (in that order of preference) that demonstrates this behaviour. I'm sorry, but I can't fix it if I can't reproduce the issue.
I have managed to reproduce sluggish performance by making my initial page very large. It seems as the size of the page (in terms of elements and text) grows, so the rate at which new inserts are made decreases. I will attach an example page that can be used to demonstrate the behaviour if anyone is interested. Approximately how large are the pages that you are editing? I'm still not certain if the slowdown is a factor of absolute byte size, or nesting of elements, etc. An example page would still be very welcome. - Ian
Created attachment 202571 [details] Large page (approx. 300kB) as a test page for sluggish editing performance.
Created attachment 202578 [details] Another page for testing sluggish performance.
Need more time to investigate.
(In reply to comment #10) > Need more time to investigate. Noted. Thanks.
When nested deeply, for example, when we have tables within tables within tables, entering even a single character potentially alters table cell layout size, which affects all other cells in the row, affecting the table, etc. The effect ripples outward, and so a lot of layout processing is performed. Much (all?) of this work is happening on the UI thread, and so the entire workbench becomes sluggish. A checkin has been made which more effectively decouples the visual and source editing views, such that switching to source-only view avoids visual layout, thus at least making the source-only view usable when nesting is deep. Further investigation to see if the visual view can be made more performant is still pending, and so the bug is not being closed at this time.
More work is required to address this issue which could involve a re-design and hence moving this out of Juno. As always, we will be happy to uptake a patch from the community.
