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 181842 - code completion after < regressed
Summary: code completion after < regressed
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: JSP (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 normal (vote)
Assignee: Tomasz Slota
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2010-03-11 06:33 UTC by Oleg Khokhlov
Modified: 2010-05-19 11:17 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
snapshot available if it helps (6.74 KB, application/octet-stream)
2010-03-11 06:33 UTC, Oleg Khokhlov 		Details
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 Oleg Khokhlov 2010-03-11 06:33:16 UTC 
Created attachment 95040 [details]
snapshot available if it helps

According to tests code completion after < regressed from 120-130ms to 170-180ms first usage and from ~70ms to 140-150ms subsequent usage.
http://aventurine.russia.sun.com:8080/PerformanceDashboard/atomicResult.jsp?projectId=5&buildNumber=201003081350&suiteName=Actions&resultName=testAllTags&resultClassname=org.netbeans.performance.web.actions.JSPCompletionInJspEditorTest&resultThreshold=1000&resultUnit=ms&history=50

Actually other similar tests like cc after <%@page, <%@include file=, etc. haven't regressed.
Comment 1 Tomasz Slota 2010-03-11 07:56:58 UTC 
The regression started from build 201002140200, Marku do you have any idea what could have caused it (as far as I can tell it was none of my changes)
Comment 2 Marek Fukala 2010-03-11 10:22:13 UTC 
It's hard to say what could caused this especially if there's only a few tests. 

For example I couldn't find similar test for x/html which is my first suspection and which would help if the problem is JSP or HTML related. Both completion providers are involved on < completion. 

In any case I reckon this is the html editor problem and can be either related with some html indexing related work or rather with a changes in jsf.editor module. But can be caused also by something completely different :-). 

I quickly glanced over the changes around this date but found nothing striking my eyes.
Comment 3 Marek Fukala 2010-05-06 11:54:48 UTC 
It's likely caused by some of the changes in EL support. 

The JsfElCompletionProvider$CCQuery.query() creates a new instance of JsfElExpression() which accesses JsfSupport.findFor(doc).getWebBeansModel(). I reckon this may take some time.

None of these actions are needed if the completion is not in EL contenxt though. I'll add a fast precheck for EL tokens at the completion offset.
Comment 4 Marek Fukala 2010-05-06 12:07:55 UTC 
web-mai#319db6b9ac2f should help, please reopen if the times are still bad.
Comment 5 Marek Fukala 2010-05-07 13:57:48 UTC 
the fix caused a serious regression: the EL code completion doesn't work if invoked just before the closing } delimiter.

So #{|} or #{bean.|} doesn't work (| == caret)http://netbeans.org/bugzilla/show_bug.cgi?id=181842#
Comment 6 Marek Fukala 2010-05-07 14:13:04 UTC 
the regression fixed in web-main#e957a871678e

I was quite surprised that tokenHierarchy.embeddedTokenSequences(...) won't return the embedded token sequence if there's an empty embedding at the given offset. Milo, is this intentional or bug?
Comment 7 Quality Engineering 2010-05-10 09:26:55 UTC 
Integrated into 'main-golden', will be available in build *201005100200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/
User: 
Log:
Comment 8 Petr Jiricka 2010-05-14 08:16:37 UTC 
Hi Oleg, can you please confirm whether or not this is fixed? I see that in the monthly performance report, there is still regression compared to NB 6.8. Thanks.