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