Community
Participate
Working Groups
Build Identifier: 20100618-0524 In the synchronize view, after selecting a large number (100 are enough) of modified files and choosing "Commit..." command, the Commit dialog appear after a long delay (about 1 minute). It is really strange, since the file list is already present (in the synchronize view). The performance of Eclipse 3.5 was excellent, the problem affect Eclipse 3.6 The workaround is to commit a small set of files at a time Reproducible: Always Steps to Reproduce: 1. Modify a large number of files 2. Synchronize with the CVS repository 3. Select the project node and execute "Commit..." command 4. Wait a ling time...
I haven't crunch the numbers, but I can imagine that the new Commit dialog (bug 124039) is a little bit slower. However, I haven't noticed the long delay you mentioned even when dealing with commits for 1k+ files (bug 299538). To prove that we'll need a performance test[1] for the new dialog, which results we could compare with the results for the old one. [1] org.eclipse.test.performance.PerformanceTestCase
(In reply to comment #1) > I haven't crunch the numbers, but I can imagine that the new Commit dialog (bug > 124039) is a little bit slower. However, I haven't noticed the long delay you > mentioned even when dealing with commits for 1k+ files (bug 299538). > > To prove that we'll need a performance test[1] for the new dialog, which > results we could compare with the results for the old one. > > [1] org.eclipse.test.performance.PerformanceTestCase Thank you very much for the quick reply. I'm sorry I have no idea how to write a PerformanceTestCase. I tried to investigate with the TPTP (again, no previous knowledge about the tool, so forgive me if I did some mistakes). I had big problems to run with the profiler, since the amount of data recorded (even with the strictest filter I could imagine) is so massive to hang my eclipse for hours. The last profiling I did, monitoring the commit dialog for a portion of the time needed to show up, showed however enough data do explain what is going on. I have a trcaxmi file (about 23 Mb), where it looks like most of the time is spent in the org.eclipse.team.internal.ccvs.ui.wizards.CommitWizard.getAllOutOfSync() method. This is strange, since IMHO the check should be done during the actual commit, and during the synchronize action. Is the check necessary even during the building of the wizard? Btw, what should I do with this big file? Upload in the bugzilla, email to you, put in an FTP server/social network etc...?
(In reply to comment #1) > I haven't crunch the numbers, but I can imagine that the new Commit dialog (bug > 124039) is a little bit slower I checked that bug, but seems to cover Eclipse 3.3. But Eclipse 3.3, 3.4, 3.5 were all fine about this issue
Created attachment 176150 [details] Performance test v01 Here is a performance test I mentioned in comment 1 which should much faster comparing to using a profiler. To run it you will need to checkout the following projects: * org.eclipse.team.cvs.ui * org.eclipse.team.tests.cvs.core * org.eclipse.test.performance * org.eclipse.test.performance.win32 To make sure we're dealing here with a performance regression the test should be run against different tags of org.eclipse.team.cvs.ui (at least R3_5 and R3_6). Alessandro, could you do that? What we need here is a prove that the new dialog opens let's say 2x longer. With the provided test this shouldn't be that hard. You can read more about Eclipse performance tests here: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.test.performance/doc/Performance%20Tests%20HowTo.html?view=co , but feel free to ping me in case of any questions. PS. I haven't checked if returning from the wizard's open method immediately affects the results. This is not final version of the test.
Created attachment 176151 [details] mylyn/context/zip
(In reply to comment #2) > The last profiling I did, monitoring the commit dialog for a > portion of the time needed to show up, showed however enough data do explain > what is going on. I have a trcaxmi file (about 23 Mb), where it looks like most > of the time is spent in the > org.eclipse.team.internal.ccvs.ui.wizards.CommitWizard.getAllOutOfSync() method. Yup, I would have started from checking that method as well. Your research proves what I suspected. Thanks. As for the profiler file, will I be able to open it with Yourkit Java Profiler? What profiler did you use? Have you tried to zip it?
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.
