Community
Participate
Working Groups
Build Identifier: Eclipse 3.4 This behaviour is seen on RAD 7.5.5.1 which is based on Eclipse 3.4 In Progress View, “Show sleeping and system operations” checked and Jsp editor open (5-10+ jsp files) This causes the cpu to cycle from 5% to 30 % (slows down work considerably – this behavior is the same for any length file, I tested 5 to 500 lines) In progress view “Show sleeping and system operations” un-checked and Jsp editor open (5-10+) – This causes the cpu to cycle from 3% to 8% (not really much of a problem but notable and potentially an indication of a runaway process in the JSP Editor – this behavior is only slightly worse for longer files 5% to 9% cpu, I tested 5 to 500 lines). Reproducible: Always Steps to Reproduce: 1.Open 5 to 10 JSP files with 5 to 500 lines 2.Open Progress view 3.In Preferences for Progress View, check 'Show sleeping and system operations'
Created attachment 175254 [details] Attaching the screenshot of yourkit to show how the Progress View is consuming time to update the toolbar values. Attaching the screenshot of yourkit to show how the Progress View is consuming time to update the toolbar values.
Source Editor does not start and stop the DirtyRegion Job on each key strok but keeps it running in the sleeping mode.SSe DirtyRegion job is not consuming CPU but in Progress View , if 5 JSPs are open all the 5 jobs are always running and the way eclipse Platform has implemented Progress view it shoots up the CPU.
(In reply to comment #2) > Source Editor does not start and stop the DirtyRegion Job on each key strok > but keeps it running in the sleeping mode.SSe DirtyRegion job is not consuming > CPU but in Progress View , if 5 JSPs are open all the 5 jobs are always running > and the way eclipse Platform has implemented Progress view it shoots up the > CPU. The sleeping mode means actually that either job has been put into a sleep or a job has been sheduled to be run after certain amount of time. I have not looked into the source code, but I expect that this jobs schedules itself very often and therefore generates heavy traffic in progress view.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
