netbeans-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lahoda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NETBEANS-45) Code completion is blocked for an extended period of time
Date Tue, 25 Jul 2017 21:49:02 GMT

    [ https://issues.apache.org/jira/browse/NETBEANS-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100842#comment-16100842
] 

Jan Lahoda commented on NETBEANS-45:
------------------------------------

Basically, each time a new javac instance is created, some packages will be listed to find
out the content of the package (either to aid the compilation, or due to an explicit request
as in this case). Even when editing a single file, it may not be possible to reuse a single
instance of javac (if the changes made to the file are too disruptive, or look disruptive),
and in addition to that, partial reparse does not work (AFAIK), so every change will trigger
a full reparse, i.e. will create a new javac instance.

> 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, 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
>
>
> 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)

Mime
View raw message