Bug 63718

Summary:	Performance regression in SourceElementParser#parseCompilationUnit()
Product:	[Eclipse Project] JDT	Reporter:	Christof Marti <christof_marti>
Component:	Core	Assignee:	Frederic Fusier <frederic_fusier>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	Tod_Creasey
Version:	3.0	Keywords:	performance
Target Milestone:	3.1 M7
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:
Bug Blocks:	60703

Description Christof Marti

2004-05-24 13:02:32 EDT

SourceElementParser#parseCompilationUnit() shows a
regression (comparing 3.0M9 to 2.1.3) when opening a Java editor (see also bug
60703 comment 13):

Results (from one average run each):

Scenario 1:
(invocation count in parenthesis)
                                         2.1.3            3.0M9       ratio
WorkbenchPage#openEditor()         4005ms (10)      6088ms (10)      152.0%
SourceEP#parseCompilationUnit()     150ms (10)       440ms (10)      293.3%
ratio                                3.7%             7.2%

(bug 60703 comment 13 mentions 450ms (16), which is a typo)

Scenario 2:
(invocation count in parenthesis)
                                         2.1.3            3.0M9       ratio
WorkbenchPage#openEditor()         2974ms (10)      3535ms (10)      118.9%
SourceEP#parseCompilationUnit()     100ms (10)       330ms (10)      330%
ratio                                3.4%             9.3%

Comment 1 Philipe Mulet

2004-05-25 03:56:31 EDT

When creating children of compilation unit, we have to parse method bodies to 
be able to find possible local types definitions.

Comment 2 Philipe Mulet

2004-05-25 03:59:20 EDT

This being said, the actual parse of the source is only a small fraction of 
the overall editor opening. 

On editor open, we normally do an entire parse so as to force problem 
reconciliation (which did also trigger entire parse in 2.1). Need to check if 
there isn't a free extra parse involved in here.

Comment 3 Tod Creasey

2005-03-07 11:54:26 EST

If this is not a performance issue please remove the performance keyword as we
are now tracking these more closely.

Comment 4 Tod Creasey

2005-03-07 11:57:30 EST

Adding my name to the cc list as we are now tracking performance issues more
closely. Please remove the performance keyword if this is not a performance bug.

Comment 5 Philipe Mulet

2005-04-06 05:19:45 EDT

Jerome - is that still an issue in latest?

Comment 6 Philipe Mulet

2005-04-06 05:28:14 EDT

Actually, reassigning to Olivier

Comment 7 Olivier Thomann

2005-04-06 09:42:12 EDT

Christof, how do you get these numbers?

Comment 8 Christof Marti

2005-04-07 12:14:14 EDT

I observed these numbers with a profiler, i.e., they could be skewed. IIRC, the
profiler showed additional time gone into parsing task tags. A corresponding
performance test case is probably better in determining whether there still is a
regression compared to 2.1.3.

Comment 9 Frederic Fusier

2005-04-08 11:59:43 EDT

I will add Scanner and Parser performance tests in perf_213 stream today...

Comment 10 Olivier Thomann

2005-04-15 15:48:40 EDT

Frédéric,

I move it to you since I won't be able to get numbers before I leave for
vacations. I am not sure there is anything to do here. This is pretty much
dependant from the parser technology. And the parsing time has been improved.

Comment 11 Frederic Fusier

2005-04-20 10:54:38 EDT

Close this bug as WONTFIX (CANNOT_FIX would have been more accurate...) due to
the fact there's nothing which can be done in this area.
As philippe said in comment 1, since 3.0 SourceElementParser goes inside method
bodies and increase time ratio does not sound foolish regarding to extra work
which is done.

Using performance test FullSourceWorkspaceBuildTests#testSourceParser() created
in HEAD and all perf_xxx streams, I got following times:
HEAD vs. 2.1.3	-251.26%
HEAD vs. 3.0	7.20%

Note that there's also javadoc comments parse which didn't exist with 2.1.3
version (this add an average of 6% to unit parse but can be more if there's a
lot of javadoc comments...).