472456 – [performance] Refresh on big project takes extremely long

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

Bug 472456 - [performance] Refresh on big project takes extremely long

Summary: [performance] Refresh on big project takes extremely long

Status:	CLOSED DUPLICATE of bug 470153

Alias:	None

Product:	Platform
Classification:	Eclipse Project
Component:	Resources (show other bugs)
Version:	4.6
Hardware:	PC Mac OS X

Importance:	P3 critical (vote)
Target Milestone:	---
Assignee:	Platform-Resources-Inbox
QA Contact:

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2015-07-13 03:58 EDT by Michael Bohn
Modified:	2015-07-16 04:56 EDT (History)
CC List:	3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Michael Bohn

2015-07-13 03:58:28 EDT

I'm working on a very big project (> 1.1 million lines of code).
Since the update to Eclipse Mars a full refresh takes more than an hour, making Mars unusable at the moment.

Comment 1 Jay Arthanareeswaran

2015-07-13 04:24:44 EDT

Which view are you on when refresh? Can you also tell me the time also include building/compilation?

Comment 2 Michael Bohn

2015-07-13 04:29:32 EDT

would classify this as 'critical' since this makes Mars unusable for me.

Comment 3 Jay Arthanareeswaran

2015-07-13 04:52:07 EDT

(In reply to Jay Arthanareeswaran from comment #1)
> Which view are you on when refresh? Can you also tell me the time also
> include building/compilation?

Please also confirm if auto build is enabled.

Comment 4 Szymon Ptaszkiewicz

2015-07-14 06:21:16 EDT

This looks like duplicate of bug 470153.

Comment 5 Stephan Herrmann

2015-07-14 06:38:03 EDT

(In reply to Szymon Ptaszkiewicz from comment #4)
> This looks like duplicate of bug 470153.

Does that imply setting -Declipse.filesystem.useNatives=false in eclipse.ini would possibly work around the problem / help narrow it down?

Comment 6 Szymon Ptaszkiewicz

2015-07-14 06:46:59 EDT

(In reply to Stephan Herrmann from comment #5)
> (In reply to Szymon Ptaszkiewicz from comment #4)
> > This looks like duplicate of bug 470153.
> 
> Does that imply setting -Declipse.filesystem.useNatives=false in eclipse.ini
> would possibly work around the problem / help narrow it down?

As a workaround maybe, to narrow down rather not. The best way to confirm it is the same problem is to get profiler output.

Comment 7 Michael Bohn

2015-07-14 06:53:15 EDT

(In reply to Jay Arthanareeswaran from comment #3)
> (In reply to Jay Arthanareeswaran from comment #1)
> > Which view are you on when refresh? Can you also tell me the time also
> > include building/compilation?
> 
> Please also confirm if auto build is enabled.

Auto-Build is _not_ enabled.

I actually never did see Eclipse build the project. I let it run over need, to check whether refresh terminates.

Refresh runs very fast to 43-47% and then takes extremely long from this point on.

Is there a tutorial for profiling reports in Eclipse? I would gladly supply some profiling data.

Comment 8 Michael Bohn

2015-07-14 06:54:08 EDT

let it run over need - let it run over night

Comment 9 Jay Arthanareeswaran

2015-07-14 12:14:10 EDT

(In reply to Michael Bohn from comment #7)
> Is there a tutorial for profiling reports in Eclipse? I would gladly supply
> some profiling data.

This is not a deadlock issue, but this might give us some idea about what's going on:

http://wiki.eclipse.org/How_to_report_a_deadlock

Comment 10 Szymon Ptaszkiewicz

2015-07-16 04:56:40 EDT

I am going to mark it as duplicate of bug 470153 since the problem started happening since Mars and the bug is opened against Mac, which is exactly the same as bug 470153.

*** This bug has been marked as a duplicate of bug 470153 ***