[
https://issues.apache.org/jira/browse/NETBEANS-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16102099#comment-16102099
]
Jan Lahoda commented on NETBEANS-45:
------------------------------------
Attila: I personally don't think copying the info from one javac instance to
another is feasible. There are lots of tiny details that would need to be
solved, and the outcome would be quite fragile. I think we are in a much better
position fixing partial reparse (and enhancing its capabilities if we need and
can).
For reusing the old data, that's a lot similar to what partial reparse does.
For the lock, one possible way of thinking would be that it prevents other
tasks from interfering with completion evaluation, allowing completion to
compute the results faster.
Wade: I suggest to file reports for "Checking for external changes" to
FileSystems, I don't think that's related to Parsing&Indexing. For the
ParserQueue.waitReady, as far as I can tell in the dumps I've seen, the threads
are stopped/waiting. So I'd estimate their impact is negligible. AFAIK, these
are not provided by the Parsing&Indexing infrastructure, these are private to
the C/C++ (CND) support.
> Code completion is blocked for an extended period of time
> ---------------------------------------------------------
>
> Key: NETBEANS-45
> URL: https://issues.apache.org/jira/browse/NETBEANS-45
> Project: NetBeans
> Issue Type: Bug
> Components: editor - Parsing & Indexing
> Affects Versions: 9.0
> Reporter: Attila Kelemen
> Attachments: callstack.csv, cnd-csm-core-parser-queue-waitready.log,
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-10.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-11.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-12.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-1.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-2.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-3.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-4.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-5.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-6.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-7.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-8.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-04-19-9.log.tdump,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-10.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-11.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-12.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-1.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-2.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-3.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-4.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-5.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-6.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-7.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-8.log,
>
> nb-jstack-cpu-high-checking-for-external-changes-with-gradle-and-maven-2017-05-30-9.log,
>
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-10.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-11.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-12.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-1.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-2.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-3.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-4.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-5.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-6.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-7.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-8.log.tdump,
> nb-jstack-cpu-high-opening-gradle-and-maven-projects-2017-01-18-9.log.tdump,
> Screen Shot 2017-07-25 at 23.11.42.png
>
>
> Often times when editting a single file, code completion blocks for an
> extensive amount of time which makes code completion practically unusable.
> Looking at the threads of the IDE, code completion and parsing seems to be
> blocked by the attached thread (holding a lock).
> Note that I do not do anything but edit a single file and this happens
> frequently during editting even though there are no external changes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
