This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 114236

Summary: LanguagesFoldManager.evaluate() implementation is slow
Product: obsolete Reporter: Marek Fukala <mfukala>
Component: languagesAssignee: Daniel Prusa <dprusa>
Status: RESOLVED WORKSFORME    
Severity: blocker CC: issues, mmetelka, pjiricka
Priority: P3 Keywords: PERFORMANCE, PLAN
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:

Description Marek Fukala 2007-08-30 12:17:28 UTC 
When profiling issue #114243 I found that LanguagesFoldManager.evaluate() is very often called (thousands of calls in
~6kB file) from ParserManagerImpl.parseAST during evaluation of the AST.

The problem is that in each call it several times calls to NbDocument.findLineNumber() which implementation is very slow
(most of the time spent in GapBranchElement.getElementCount() and GapList.size() ).
Comment 1 Jan Jancura 2007-08-30 17:55:32 UTC 
We will look at it.
Comment 2 Petr Jiricka 2007-11-15 18:05:54 UTC 
Hi, is this still relevant?
Comment 3 Daniel Prusa 2008-01-21 13:27:52 UTC 
I have made some measuring regarding this issue, it seems that the number of NbDocument.findLineNumber() calls is
smaller comparing to the number observed by Marek when he used a build dated to Aug 30. I am not sure why, but it can be
caused by optimizations done in AST's as well as by a smarter feature querying.

The number of calls was proportional to the number of folds. I have tested it using a 190kB js file (having 5264 lines).
When parsing the file, 1180 calls of findLineNumber() were performed. Cumulative time of the calls was cca 32
milliseconds, while the whole parsing time was about 3 seconds. 
Performance on an another big js file was similar.

I plan to make some more measuring using sources different to javascript.
Comment 4 Daniel Prusa 2008-01-23 11:34:29 UTC 
Additional measuring results:

html file, 422kB, 8159 lines
number of NbDocument.findLineNumber() calls: 7054
cumulative time of the calls: cca 500 ms
total parsing time: cca 8200 ms

Comparing to javascript, findLineNumber() is called more often for html, but the ratio between the cumulative time spent
in the method and the total parsing time is still acceptable => closing this issue.