You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@netbeans.apache.org by "Michael Bien (Jira)" <ji...@apache.org> on 2022/05/22 09:22:00 UTC

[jira] [Commented] (NETBEANS-6504) java code completion slow - poor algorithm choice

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

Michael Bien commented on NETBEANS-6504:
----------------------------------------

hi [~notzed] , would you like to open a PR on github?

This issue tracker is also no longer used since it moved to github too. Make sure you link this issue in your PR.

PRs will trigger the tests and make review easier.

> java code completion slow - poor algorithm choice
> -------------------------------------------------
>
>                 Key: NETBEANS-6504
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-6504
>             Project: NetBeans
>          Issue Type: Bug
>          Components: cnd - Code Completion
>    Affects Versions: 13
>         Environment: gentoo linux, slackware64-current.  btrfs and jfs.  openjdk18, 32GB RAM, 1TB NVME SSD PCI3x4.
> i do not believe this is related to the other bug reports of slow completion which seem to be platform specific (ntfs).
>  
>            Reporter: notzed
>            Priority: Major
>         Attachments: slow-complete-full.patch, slow-complete-simple.patch
>
>
> I have a class with a mere 3000 constants and it takes a few hundred milliseconds to show and (it seems to run twice?) delete the completion popup when these constants are imported using a wildcard static import.  This makes editing extremely tedious and heavily drains a laptop battery.
> I tracked it down to ElementUtilities.isHidden() invoked from getLocalMembersAndVars() using an inefficient algorithm to filter results. Most of the time time is spent in in toString() via Name::compareContents().
> Perhaps there's a reason it isn't used in this case but addIfNotHidden() seems to have been written to address this performance issue but is only used in one of the methods which callls isHidden().
> I've attached a couple of patches.  One just changes getLocalMembersAndVars() to use addIfNotHidden(), the second is more complete and changes all uses of isHidden() to use addIfNotHidden() in a consistent way and also removes the redundant name comparison in the inner loop.
> I'm sorry, i'm not sure how to trigger all code paths to test the patches.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@netbeans.apache.org
For additional commands, e-mail: commits-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists