Community
Participate
Working Groups
I created a new project with 6500 resources in an empty workspace. I then committed the new project to a CVS repo. Processing seemed to go in three steps: - 2 minutes where it seemed to create the directory structure - 2 minutes where it was pushing about 65M of content - 5 minutes of updating CVS sync information (Note: all times are very approximate but show rough scale) The last time is the most surprising since the CPU was at 100% (i.e., we did not seem to be hitting the server) and the CVS info was brand new so there should not have been too much comparing etc going on.
I too have noticed that the saving of sync information is taking much longer than you would expect. If 65MB was transfered over the wire in approx. 2 minutes than there is no reason that saving the sync info to disk would take any longer. IMHO, this is pretty important to investigate for RC2.
Gee, Jeff gets on other people's cases for not marking performance bugs "performance" :)
Pretty sure this is related to Bug 28343. Which will be fixed by the UI team in RC2. Basically the decorator was over-updating in the wrong thread. Tod will be fixing this. As a result, all CVS operations take a whil to complete. The reason "CVS saving sync info" is shown is because this is when the cvs state change events are broadcasted and the decorator is a listener.
Note that CVS decorators were NOT on during any of this work. This is a fresh biuld, fresh workspace and the decorators are off by default. More information/additional scenario... After the initial commit of 6500 resources we deleted all in our workspace and got new ones with slightly different content. Using the same technique as before, we shared them with the same repo. That initial sharing took 5 minutes. Progress was reported well but the overall time seemed long. Once we got the sync view up, everything was a conflict (this is expected because we had deleted everything locally including the sync info). We selected all and did "override and commit". The progress dialog came up saying "Operation in progress" and there was no other feedback for over 7 minutes. I then left for about 45 minutes. When I returned the operation had completed (so I don't know how long the operation really took). During the initial 7 minute period, the CPU was hovering around 2-6% with most of that time going to Eclipse. Side note: The exact scenario we are doing is to make a copy of several versions of the platfrom from one repo to another. Here are the steps: - grab all the projects related to a particular version of the platform (M5 RC1 in our case) - disconnect all - shutdown eclipse - in the filesystem, move all the projects under the dir structure org.eclipse.equinox/plugins in the workspace dir. - delete the .metadata dir - restart Eclipse and make a project called org.eclipse.equinox - follow the steps outlined for sync and commit etc.
some profile results that point to some bad performance problems: - on initial commit 28% of time is spent updating the CVS console that isn't even visible or created yet. Worse yet, on initial add from the sync view console updating is taking 60% is operation. - on initial share isIgnore() is taking over 40% of operation time and I suspect a large amount of memory for operation scoped vars. I don't even think this test is important on share. Haven't had a chance to test the override and commit yet.
Kevin wanted to take a crack at this one.
Buffer console and don't do async unless the console is open. Also ensure only one async at a time. Document no longer buffers since console now does this. Policy.java new revision: 1.6; previous revision: 1.5 ConsoleDocument.java new revision: 1.5; previous revision: 1.4 Console.java new revision: 1.21; previous revision: 1.20 Still to fix: - remove preference for "auto open console"
cvs ci -m "33156 - removed "auto open console" pref - console font now updates when pref ICVSUIConstants.java new revision: 1.49; previous revision: 1.48 Console.java new revision: 1.24; previous revision: 1.23 messages.properties new revision: 1.248; previous revision: 1.247 There should be a seperate bug report for isIgnored().
*** Bug 35242 has been marked as a duplicate of this bug. ***
