Bug 63718 - Performance regression in SourceElementParser#parseCompilationUnit()
Summary: Performance regression in SourceElementParser#parseCompilationUnit()
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M7   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks: 60703
  Show dependency tree
 
Reported: 2004-05-24 13:02 EDT by Christof Marti CLA
Modified: 2005-04-20 10:54 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christof Marti CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2005-04-06 05:19:45 EDT
Jerome - is that still an issue in latest?
Comment 6 Philipe Mulet CLA 2005-04-06 05:28:14 EDT
Actually, reassigning to Olivier
Comment 7 Olivier Thomann CLA 2005-04-06 09:42:12 EDT
Christof, how do you get these numbers?
Comment 8 Christof Marti CLA 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 CLA 2005-04-08 11:59:43 EDT
I will add Scanner and Parser performance tests in perf_213 stream today...
Comment 10 Olivier Thomann CLA 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 CLA 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...).