Hello,

I know we have native file listeners which are super snappy but I now
think NetBeans is too eager to scan folders!

For example, I see the IDE take a lot of CPU doing 'Background
scanning of projects' and that background scanning seems to eagerly
index the build/ classes that Gradle is just generating after being
invoked by me in the terminal.

So, NetBeans is effectively slowing down the overall compilation by
grabbing CPU and IO too soon.

I wonder if we could apply different strategies here, maybe some smart
delays or throttling? I suspect the overall experience would be better
if the IDE would index *after* Gradle is done.

I'm also wondering if the whole Lucene backend we have is not
re-indexing the same things too often. Maybe just doing a hash on a
file is faster than revisiting and reindexing the whole .class. I
would like for this part to be pluggable. I'm curious if using some
other indexing backend would make the IDE more snappy. It's been a
while since I looked at that code so I can't remember how modular it
all really was... I think most of it is built with Lucene in mind.

--emi

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Reply via email to