Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333785

Summary:

Performance problem with Create Patch

Product:

[Technology] Subversive

Reporter:

Joe Breher <jbreher>

Component:

Assignee:

Igor Burilo <igor.burilo>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

robert.elves, steffen.pingel

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows XP

URL:

http://www.eclipse.org/forums/index.php?t=rview&goto=647588#msg_647588

Whiteboard:

Bug Depends on:

Bug Blocks:

287559

Attachments:

Description	Flags
data on eclipse & plugins	none
thread dump - jvisualvm	none

Description Joe Breher

2011-01-07 16:07:32 EST

I initially reported this on the forum:
"
I am a relative newcomer to using mylyn/Tasktop with Subversive in a distributed C++ environment. mylyn & Tasktop were added about a week ago, the other components I have been using for several months.

Just as of today, Create Patch has started taking intolerable amounts of time, with eclipse.exe consuming ~50% of a relatively decent Core 2 Duo machine.

Create Patch is being invoked from the Synchronize view - I am right-clicking the relevant project under the relevant change set, and selecting Create Patch... off the context menu.

I can name the patchfile with no issues. However, any change to the 'Include changes' window causes the CPU to peg for approximately 5-10 minutes. e.g. deselect the root of the project, wait five minutes. select one file, wait ten minutes, select another file, wait seven minutes...

I tried restarting eclipse. Same behavior.

I tried rebooting the machine. Same behavior
"
I got this reply from Dani Megert:
"
Please file a bug report and attach stack traces that show where the time is spent.
"

What build of Eclipse you are using
- see attached file eclipse-help-about-details-configuration.txt

What VM you are using (version and vendor). Use "java -version" to find out version information.
C:\Documents and Settings\JBreh7100805>java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

What you were doing at the time of the deadlock (what dialog, wizard, editor, etc)
- Synchronize view > rt-clk on project > Local > Create Patch ... > select or deselect folders or files in the Include changes window. Each selection or deselection puts the UI to sleep, with CPU pegged (as viewed by taskmgr.exe), for 5-10 minutes

Whether it is reproducible; if so, provide steps
- Yes, it is reproducible in multiple projects, and multiple change sets. see above for steps to recreate.

Once the bug report is created, attach a stack trace (also known as thread dump), using the "Create a New Attachment" link in bugzilla.

Comment 1 Joe Breher

2011-01-07 16:09:02 EST

Created attachment 186315 [details]
data on eclipse & plugins

Comment 2 Joe Breher

2011-01-07 16:16:21 EST

Explicitly adding files under the project heirarchy to SVN's ignore list seems to reduce the amount of time spent waiting on the machine out to lunch. I am doing this from
Synchronize view > select project > rt-clk on files not needing CM > Add to svn:ignore

However, this seems to be required per project, per change set - each change set seems to be populated with products from the build process, not needing CM, even though they have already ben explicitly added to svn:ignore from another Change Set in the same project.

I am working on getting a stack trace....

Comment 3 Steffen Pingel

2011-01-07 16:28:39 EST

Moving to Subversive. Please capture a stack trace when the problem occurs and attach it: http://wiki.eclipse.org/Mylyn_Contributor_Reference#Debugging .

Comment 4 Joe Breher

2011-01-07 16:44:16 EST

I am trying to use the adaptj mechanism for obtaining a stack dump. The instructions at the link above state:
On Windows use the tool found at the adaptj home page:
    * Follow the link and select button "Launch" and run the applet
    * Select menu Process > Thread Dump
    * In the combo box "Process ID" select the Java VM and click OK 

I am able to launch the applet. However, the other two steps seem to be reversed? Thread Dump is greyed out on the Process menu unless I first make a selection in the Process ID box. Even at this, I seem to be encountering an issue. Here is the output in the lower window of the StackTrace tool, showing the results from both the running processes on my machine:

5424 javaw.exe ( StackTrace - <Untitled> ) session:0 threads:23 parent:4784
There is no valid license.
================================================================================

5660 java.exe ( Create Patch ) session:0 threads:60 parent:4292
There is no valid license.

I'll try to employ another mechanism for captureing the stack trace. Please be patient - I'm not a Java guy, and these tools are new to me.

Comment 5 Joe Breher

2011-01-07 17:00:32 EST

I need to retract a statment above - I am not in fact seeing artifacts that must be added to the svn:ignore list on a per-project, per-changeSet basis. Once added to svn:ignore for a given project from within a change set, they seem to be handled appropriately for other change sets.

Still encountering difficulty obtaining a stack trace. Method 2 fails as well. The Create Patch window is modal. Accordingly, I cannot get to the Console view to enter a Ctrl-Break.

Comment 6 Joe Breher

2011-01-11 13:38:59 EST

Created attachment 186540 [details]
thread dump - jvisualvm

I think this is the requested thread dump. I captured this using jvisulvm during the time the UI for the Create Patch was stalled.

Comment 7 Alexander Gurov

2011-08-01 13:05:44 EDT

Thank you, all the information was helpful.
I've simplified code and reduced amount of calls to the tree UI. Fix will be included into the next development build.
If there still some issues with this functionality even after the fix is applied, then please reopen the report.