Community
Participate
Working Groups
Build Identifier: 3.2.3 It seems that WTP is doing some work even if the user does nothing. This can be seen the debug console: 2011-04-11 12:09:06,665 [ Worker-66] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor 2011-04-11 12:09:07,212 [ Worker-50] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor 2011-04-11 12:09:07,759 [ Worker-36] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor 2011-04-11 12:09:08,305 [ Worker-47] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor 2011-04-11 12:09:08,852 [ Worker-68] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor 2011-04-11 12:09:09,399 [ Worker-106] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor 2011-04-11 12:09:09,946 [ Worker-89] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor 2011-04-11 12:09:10,493 [ Worker-91] DEBUG JobStatsManager - ignoring job: org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor ... The situation gets worse for each jsp file which is opened - this will cause a new StructuredRegionProcessor to do some work (even on idle). As an result - if many jsp editors are open - eclipse has to spawn many worker threads which have to be created, managed and synchronized and may cause additional delays. And BTW: Please avoid calling Thread.setPriority() for short running tasks (like StructuredRegionProcessor) - it's an expensive operation. As a consequence that WTP is fighting with the Eclipse Worker Pool which resets the thread priority back to normal so both the jvm and the OS are kept busy with changing thread priorities. (ca. 10% CPU usage on my machine using the steps below) Reproducible: Always Steps to Reproduce: 1. Open 100 different (mid-sized) jsp files simultaneously 2. Look at debug log, cpu usage, synchronization effort, number of workers 3. Work with eclipse - you see that it's some kind of "handicapped" and slower. If you have a chance, try this on a single core machine, the situation gets even worse there.
Hi Patric, Thanks again for your continued investigation into Source Editing. Each of these instances of StructuredRegionProcessor is a reconciler for the opened editor. So the number of threads you see is to be expected. When opening 100 editors all at the same time, each editor performs its initial reconciling of the document to generate things like spelling annotations, as-you-type validation errors, and semantic highlighting. But, we definitely don't want to do work when there's nothing to do be done. So after that initial pass, each reconciling thread needs to check to see if any work has been add to its queue. As long as nothing's been modified in the document, the job is just rescheduled. I believe this is what you see as heavy-weight in this: the constant rescheduling. So I think we might be able to go at this by trimming some of the fat, and going with a Thread implementation similar to AbstractReconciler's BackgroundThread. While I understand the aggravation from this, I'm toning down the severity based on the Eclipse bugzilla definition of 'critical'.
Created attachment 193100 [details] patch Shot at a patch. With the BackgroundThread, I didn't notice any periodic spikes like would occasionally happen with the Job implementation.
New Thread-based implementation checked into HEAD.
Thank you, Nick. Will the patch also be part of the upcoming 3.2.4 release?
You're quite welcome, Patric. I had not planned on releasing this to 3.2.4 as I felt the changes might be a little drastic for a maintenance release, especially being fairly late in the development of 3.2.4.
