Community
Participate
Working Groups
Hello, We have a performance problem when synchronizing a project. My cvs server is cvsnt version 2.5.03.build 2260. It is configured as described in the eclipse cvs faq. The synchronizing operation is 3 or 4 times slower than eclipse 3.1.2. Example for a project with 487 java files : With eclipse 3.1.2 it takes 8s (cf cvssync312.log ) With eclipse 3.2.0 it takes 32s (cf cvssync320.log )
Created attachment 47210 [details] log with eclipse 3.1.2
Created attachment 47211 [details] log with eclipse 3.2.0
I don't reproduce the problem if i disable in the cvs preferences "allow models to participate in synchronizations".
Given that you have found a work around, this is not a priority for 3.3.
We do not have the manpower to address this issue in 3.3. This FAQ ebtry describes in more detail the workaround mentioned in comment 3. http://wiki.eclipse.org/index.php/CVS_FAQ#Synchronizing_has_some_regressions_in_Eclipse_3.2._Why.3F
One possible cause of this is that the 3.2 synchronize operation also fetched the contents of any changed files. Can you give us an idea of how many incoming changes there were (or if there were any at all).
(In reply to comment #6) > One possible cause of this is that the 3.2 synchronize operation also fetched > the contents of any changed files. Can you give us an idea of how many incoming > changes there were (or if there were any at all). With eclipse 3.2.2 , when the project has no incoming changes : 20 s if "allow models to participate in synchronizations" is enabled and 7 s if it is disabled
*** Bug 181754 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > *** Bug 181754 has been marked as a duplicate of this bug. *** > You asked me to give feedback on Bug 181754 and to describe the steps I take when synchronizing and the number of incoming and outgoing changes involved. To synchronize: right-click on an existing shared project and select Team/Synchronize with repository. With "allow models to participate in synchronization" activated this hangs quite a time on "Operation in progress...\nReceiving file: Template". Remark that Template is not a file from the project. Their are no incoming nor outgoing changes. Deactivating the option mentioned reduces CVS process from about 30 to 3 seconds for about 1300 files. If you want any additional info I'd be glad to help.
(In reply to comment #8) > *** Bug 181754 has been marked as a duplicate of this bug. *** > Just noticed the 2 files that zugasti has added. I think these are very similar to the things I notice. I notice that -in my case- most of the time is spent on "Receiving file: Template", and that this corresponds to a lot of "clear-static-directory" operations/log lines. So this seems to be the slow part/additional step(?) in Eclipse 3.2 (and later?). I try to see what happens using the latest build for Eclipse 3.3.
The Template file is a CVS configuration file. Could you tell me if you had any outgoing or incoming (or conflicting) changes after you synchronized? The main difference between the two Synchronization types is that the model-based synchronization fetches contents as part of the Synchronize (making update faster). Do you get the same timing if you press the Synchronize button in the view itself (this will refresh the page in the Sync view instead of potentially replacing it). You could try 3.3 just to see but I don't recall making any changes that would have affected performance. However, it would be good to know whether the performance characteristics changed.
What I tried: - fresh install of Eclipse 3.3M6 buildId: I20070323-1616. - checkout of a project. - synchronize that project (in the Synchronize view using the synchronize button) Result of synchronization was always no incoming (finished project) and (of course) no outgoing changes. - with "Model participation": slow, slow....+-30seconds - without "Model participation": very good response times +-3 seconds
Perhaps this is somehow related to the project structure. Can you provide answers to the following questions: 1) How many projects are you synchronizing 2) How many files? 3) How many folders? 4) How many empty folders? To find this out, you would either need to check into the server and count the folders there (sorry, I don't know what tool would help you out there) or disable pruning on the CVS preferences page and check out the projects from scratch (i.e this will create all folders even if they are empty). 5) How many of the files are marked as text (anything but -kb)? How many are binary (-kb).
Created attachment 63582 [details] cvsLogWithModelPartication 3.3M6
Created attachment 63583 [details] cvsLogWithoutModelPartication 3.3M6
(In reply to comment #13) Instead of answering all your questions (will take some time, so I'll try to answer it later); I've added two log files taken with and without Model participation. The interesting part -I think- is in the log with model participation starting form line 1359: Clear-static-directory ./ I think this part (and what follows) is not present in the other log file, and it's this part of the log that takes most of the time when synchronizing.
Thanks for the logs. I believe that all the information I asked for can be deduced from the logs so we should have enough information to try and reproduce the issue.
I think the real problem I am having with this is what is already stated below: "One possible cause of this is that the 3.2 synchronize operation also fetched the contents of any changed files." So when a large file has been changed that is 20 meg syncing takes forever. It used to be fast and that update actually did the fetching. Many times we sync but don't take the updates. Hopefully we can move back to not fetching on synchronize or only do it if model support is enabled.
The contents are only prefetched when model participation is enabled. When model participation is enabled, we need to prefetch the contents because a model may want to have access to the contents when rendering the Synchronization tree. Disabling model participation results in a Synchronization that is identical to 3.1.
This problem seems to be solved in the final release of Eclipse 3.3. I've just ran some tests: with and without model participation. I don't see any difference in response times.
Oups sorry. I was a bit too quick. I tried with and without the models mentionned in (Change Sets, Java Workspace and Workspace): Window -> Preferences -> Team -> Models and did not notice any difference. However when enabling the models under Window -> Preferences -> Team -> CVS ->Synchronze/Compare -> Allow models to participate in synchronizations I keep having the same problems; really slow when this is enabled (20 seconds instead of 2 with no incoming nor outgoing changes). So not solved in Eclipse 3.3
I've create a performance test (Bug152581Test.java) from the data provided and here is a summary of my findings: 1) A CVS server on a Linux box is about 3 times faster than CVSNT on the same box I am running Eclipse on. I expected some slowdown since the server and client are the same machine but not that much. I do know that, traditionally, CVSNT does not perform as well as th *nix CVS. 2) Using CVSNT, the old-style synchronization is almost 3 times faster that the model based synchronization for the two cases attached to this bug (i.e. no local or remote changes) 3) The model-based synchronization takes about the same time as an update. This is expected since the model based synchronization is performing a standard cvs update to a virtual sandbox. 4) In the past, when using stopwatch testing against the dev.eclipse.org projects in my workspace, I didn't see as much of a difference between the two synchronizations. One possible factor is the network latency (i.e. could a higher network latency bring the timings for the two cases closer together). Another is the project structure. Here are the numbers I got from CVSNT Case 1 (first two attachments) Old-Style 8.12s Model 22.21s Update 28.64s Case 2 (next two attachments) Old-Style 4.26s Model 11.36s Update 9.94s As an aside, I have added the following to the wiki to capture the difference between the two synchronization types. http://wiki.eclipse.org/CVS_Hacks#Synchronization To summarize, the old-style synchronization is highly optimized and has some undesirable side effects whereas the model-based synchronization, while slower, performs a more standard cvs operation and makes the content accessible to logical models and users as part of the synchronize operation. Given that both styles have benefits, I am inclined to leave things as they are for now. In 4.0 we can revisit the issue if we feel that we do not want to support the two styles of synchronization.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
