[
https://issues.apache.org/jira/browse/NETBEANS-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861667#comment-16861667
]
Shevek commented on NETBEANS-2291:
----------------------------------
1a. Could be number of open files.
1b. Not likely to be fs type; I do EVERYTHING on this fs, and e.g. git, which
manipulates the same fileset, is blindingly fast.
/dev/mapper/xubuntu--vg-root / ext4 rw,relatime,errors=remount-ro 0 0
nvme0n1p5_crypt: 0 3999291392 crypt aes-xts-plain64
Unix tools can scan, sort, filter, etc the entire tree in about 0.5 seconds.
Currently showing 25Gb of disk buffers in kernel RAM, so it's not even going to
disk. I can probably repro on a massive ZFS RAID, but I doubt that'll make a
difference.
1c. Not likely to be disk, it's NVMe, I do heavy I/O on it regularly, it
behaves great, but this NB process is running on an otherwise idle system, so
nothing is interfering.
2a. Very likely, from my observations. See NETBEANS-2606
2b. If NetBeans is watching the build/ directories as well, and I think it is
(and shouldn't be?), then there's about 0.25 million files here, although only
50K of those are Java files.
3. Could be. Hard to tell. I mean, doing a context-switch into kernel in a
routine which the enclosing library thinks is a simple memory-read, and is
algorithmically designed that way, is never going to be great...
> NetBeans is unusably slow
> -------------------------
>
> Key: NETBEANS-2291
> URL: https://issues.apache.org/jira/browse/NETBEANS-2291
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
> Affects Versions: 8.2, 10.0, 11.0
> Environment: Ubuntu 18.10
> Linux 4.18.0
> 12 core Xeon E-2176M with 64Gb RAM
> -Xmx2536m (2.5Gb for NB, of which it uses about 1.7G)
> NetBeans 10vc2, 10vc5, 8.2
> JDK 11.0.1
> JDK 1.8
> G1GC, CMS GC, Serial GC
> Reporter: Shevek
> Assignee: Laszlo Kishalmi
> Priority: Critical
> Labels: performance, usability
> Attachments: nb-11-slow-hotspots.png,
> netbeans-10vc5-jdk8-hang-gototype.txt.tdump,
> netbeans-10vc5-jdk8-hang-progressutils.txt.tdump,
> netbeans-10vc5-jdk8-hang.txt.tdump, netbeans-slow-00.npss,
> netbeans-slow-01.npss, open-file-slow-01.txt.tdump,
> open-file-slow-02.txt.tdump, open-file-slow-03.txt.tdump, slow-stack-00.txt
>
>
> I used to use NetBeans 8 on JDK8, it was tolerable, but slow.
> Now I have a new laptop, I've tried nb8, nb10 on jdk8, jdk11, with g1gc,
> cmsgc, other gc. They are all UNUSABLY slow. By which I mean, it takes over a
> minute just to open a file.
> Mostly this is because things are waiting for things waiting for very
> inefficiently implemnted file I/O, editor parsing, or things like that. I've
> watched a 12-core Xeon chip spend over 4 hours just attempting to handle the
> Active Reference Queue Daemon thread.
> The slowdown is somewhat incremental - I can escape it as long as I'm happy
> to restart NetBeans every hour or so (which I'm not happy to do).
> Attached a stack dump to get you started, this took over a minute to open a
> 284-line Java file from idle.
> Please feel free to ask all the obvious questions, although I'm fairly sure
> all the obvious things have been done. Mostly, I've got GC down to a
> negligible amount.
> If there's one or more features of NetBeans I can disable to get acceptable
> behaviour while still being able to realistically edit Java code, please tell
> me and I will disable them because I am at the end of my rope after using
> (and developing for) NetBeans for nearly 10 years. If I can get IntelliJ to
> load a Java/Gradle project neatly before this gets fixed, I'm gone.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
