Community
Participate
Working Groups
Build Identifier: 20100617-1415 When I open the Team Synchronize Perspective and have a very large number of changed files, marking them takes extemly long time. This especially evil when I expand all and then select certain files holding the CTRL key. The first few files are ok, but after the first files are selected each followng files will take longer and longer until it is actually selected. Looks like the repaint operation is implemented expensively, but this is only a guess. Please tell me, if you need more info. Reproducible: Always
Is "marking" the term you use for "selecting"?
Yes. I am selecting the changed files by selecting the first one, then holding the CTRL key and selecting others.
Looks like there's a slow selection listener on the tree (when the selection is large). The longer the selection listener takes, the more you see bug 177309 (at least on Windows; I don't know your platform, could you please set your platform on this bug?).
I set the platform to "All", because I observe this behavior on both Linux and Windows. So I assume, it will also show up on the Mac.
btw, in the bug, referred to in comment 3, you always talk about shift selection. I just want to note, that I didn't use shift, but CTRL here. I only select the first bigger group with shift. After that I unfortunately have to select all further items one by one holding the CTRL key, because I cannot do the following: (some items are already selected) hold CTRL select an item hold shift select a whole group keeping the rest of the selection intact This works in some other views and would be very handy here, too.
(In reply to comment #0) > When I open the Team Synchronize Perspective and have a very large number of > changed files, marking them takes extemly long time. How large have to be the change set in order to observe this? I gave it a try with over 1k outgoing changes and I didn't see any lags. Are you sync'ing with Logical Models on? If yes, what models are you using (All Models, Java, other)?. Have you expanded all the items before selecting? (In reply to comment #5) > After that I unfortunately have to > select all further items one by one holding the CTRL key, because I cannot do > the following: This is a different issue, please file a separate bug for it.
I think, a hundred changed files plus containing folders (flat presentation) should be enough. Yes, I expanded everything using the "plus" button in the "Synchronize" view's header.
(In reply to comment #7) > I expanded everything using the "plus" button in the > "Synchronize" view's header. There is no such button for CVS synchronizations. You're sync'ing with a SVN repo, aren't you? Are you using Subclipse or Subversion?
(In reply to comment #5) > I only > select the first bigger group with shift. After that I unfortunately have to > select all further items one by one holding the CTRL key, Are you saying that it's only slow if you use 'Ctrl' to select but not if you use 'Shift'?
Yes, I am syncing with SVN. And I forgot to say, that I am writing code in Java. Though there are images or html files or other kinds of files here and there. Does this answer the question about the "model"? I didn't try to use the shift key. Every single further selection (one more item) takes so dammed long, I just didn't want to waste the time it already took to try selecting using shift. But since the right-click on the selection (to choose "commit") takes just as long and CTRL+A takes very long, too, I assume, it's the same for shift selections.
Upps! Using subclipse.
Please create a few stack dumps while waiting. This will help us to locate the problem. See http://wiki.eclipse.org/index.php/How_to_report_a_deadlock on how to do this.
I tried to start eclipse with the command line parameters given in the linked wiki. But it didn't create a stack dump. I would have wondered, if it had, because it is just slow, but doesn't run out of memory.
(In reply to comment #13) > I tried to start eclipse with the command line parameters given in the linked > wiki. But it didn't create a stack dump. I would have wondered, if it had, > because it is just slow, but doesn't run out of memory. Creating the stack dump is not related with the memory. You have to do it manually several times while it's "slow".
Marvin, if you're on Windows and using JDK 6 you should be able to follow these instructions: http://wiki.eclipse.org/How_to_report_a_deadlock#Using_jvisualvm_.28Java_6u7_or_later.29 . Ping me if you need any more info on how to do this.
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.
