https://bugs.kde.org/show_bug.cgi?id=384880
--- Comment #2 from RJVB <rjvber...@gmail.com> --- If CMakeLists.txt files are to be monitored that should be an additional action taken by the CMake project manager, not by a generic file manager. And that was once necessary it should not be removed until support for older cmake versions is officially and completely removed. (Which in turn shouldn't happen until cmake server mode works as reliably and efficiently as the json-based mode, IMHO). The venom is in this call: d->m_watchers[project]->addDir(project->path().toLocalFile(), KDirWatch::WatchSubDirs | KDirWatch:: WatchFiles ); Removing the KDirWatch::WatchFiles should already be an improvement, but I'd hope that doing the addDir() only for folders that are actually being loaded might at the same time avoid putting a monitor on excluded folders. Assuming that's OK of course. > b) Maybe. I've queried the Qt ML for feedback on this, and for the existence of a dedicated benchmark but I'm going to go with the null hypothesis that the QFSW API isn't new and has had ample opportunity for fine-tuning by Qt experts. We're just using it in a very intensive way here. I think that the GCC source tree contains almost 8000 files in I don't know how many directories. It doesn't strike me as odd that memory allocation and string comparisons show up as hotspots when creating or deleting that many QFSW entries involve that kind of operation. I'm a bit surprised that "only" 8000 or so allocations and string comparisons can be that expensive in terms of processing time but not incredulous. It's really not something I want to dig into at the moment. -- You are receiving this mail because: You are watching all bug changes.
