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 233208 - CodeCompletion took 3130 ms.
Summary: CodeCompletion took 3130 ms.
Status: RESOLVED WORKSFORME
Alias: None
Product: php
Classification: Unclassified
Component: Editor (show other bugs)
Version: 7.4
Hardware: All All
: P3 normal (vote)
Assignee: Tomas Mysik
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2013-07-22 18:39 UTC by mrpc
Modified: 2016-06-16 08:06 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 202397


Attachments
nps snapshot (80.19 KB, application/nps)
2013-07-22 18:40 UTC, mrpc
Details
nps snapshot (172.21 KB, application/nps)
2013-07-29 05:30 UTC, Petah
Details
nps snapshot (157.35 KB, application/nps)
2013-07-29 19:58 UTC, Exceptions Reporter
Details
Screenshot (88.00 KB, image/png)
2014-07-23 11:40 UTC, Tomas Zezula
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mrpc 2013-07-22 18:39:58 UTC
This bug was originally marked as duplicate of bug 231108, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE Dev (Build 201307212300)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.6-b04, Java(TM) SE Runtime Environment, 1.7.0_10-b18
OS: Windows 8

User Comments:
mrpc: Actually i tried to invoke code completion after netbeans startup and while it was opening projects and scanning them, so I think it's ok.
However, perhaps it should at least work with the default code templates of netbeans until it finishes the scan, perhaps with a little warning [netbeans is still scanning your projects], instead of just being too slow. Just an idea.



Maximum slowness yet reported was 3130 ms, average is 3130
Comment 1 mrpc 2013-07-22 18:40:00 UTC
Created attachment 137584 [details]
nps snapshot
Comment 2 Marek Fukala 2013-07-23 11:22:51 UTC
HTML code completion runs a parsing task and waits for 1.9seconds for the parsing lock being held by repository updater - TLIndexer. 

I do not know what I could do about it to speed it up. I run a priority parsing task, but it is blocked by background scanning from some reason. The data from the TLIndexer are not necessary for the requested parsing result. Tome, can some kind of parsing level/scope be defined somehow so tasks with certain level/scope wouldn't wait for the others? I have no idea how the tasks in the parsing queue are processed now...
Comment 3 Petah 2013-07-29 05:30:59 UTC
Created attachment 137917 [details]
nps snapshot

Problem?
Comment 4 Exceptions Reporter 2013-07-29 19:58:01 UTC
Created attachment 137963 [details]
nps snapshot

some code
Comment 5 Tomas Zezula 2014-07-23 11:37:08 UTC
Blocked by PHP occurrences finder, see screenshot.
Comment 6 Tomas Zezula 2014-07-23 11:40:20 UTC
Created attachment 148235 [details]
Screenshot
Comment 7 Tomas Mysik 2016-06-16 08:06:48 UTC
snapshot-682387 - parsing, HTML editor:
org.netbeans.modules.html.editor.api.gsf.HtmlParserResult.getErrorsFromValidatorService ()	1 921 ms (81,4%)	1 921 ms (82%)

snapshot-682418 - deep PHP class hierarchy:
org.netbeans.modules.php.editor.elements.IndexQueryImpl.getInheritedByTypes ()	6 872 ms (79,7%)	6 872 ms (79,7%)

snapshot-682937 - JS parsing:
org.netbeans.modules.javascript2.editor.model.Model.resolveLocalTypes ()	15 017 ms (100%)	15 017 ms (100%)

snapshot-683525 - deep PHP class hierarchy:
org.netbeans.modules.php.editor.elements.IndexQueryImpl.getInheritedTypeMembers ()	15 634 ms (100%)	15 634 ms (100%)

snapshot-683704 - deep PHP class hierarchy.

All reports are from year 2013 so closing this issue as WORKSFORME. Let's wait for reopening or a new issue.

Thanks for reporting.