https://bugs.kde.org/show_bug.cgi?id=427481
--- Comment #2 from Igor Kushnir <igor...@gmail.com> --- (In reply to Milian Wolff from comment #1) > If this is important for your workflow, and you really need to have it > fixed: Adding a vector of projects to every item will have a big performance > impact if done naively. I would prefer not to do that. Rather, can't we > check when a file is removed if there's another project that still contains > it? Afaik that's a matter of iterating through the list of still-opened > projects and doing a quick hash lookup each time. That will ensure that the > performance impact of loading a project is minimal, and we also won't have > to store more data in memory either. This is not important to my workflow, but I like to make the code work right unless it causes other issues. I tried to modify ProjectFileDataProvider::projectClosing() to fix this bug. First I merged all file sets from still open projects (obtained by a call to IProject::fileSet()) into one QSet, then removed all elements of m_projectFiles that weren't in this set. But this turned out to be very slow compared to my optimizations in https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/187. Then I tried to store the file sets in a std::vector<QSet<IndexedString>> and remove all elements of m_projectFiles that weren't in any of the sets. projectClosing() became much faster with this change, but not nearly as fast as the optimizations in the aforementioned merge request. For example, consider closing many projects at KDevelop exit, the last two of which are WebKit with almost 320 thousand files and kdevelop with a little more than 67 thousand files. With the merge request's optimizations, closing a project (that may even contain less than a thousand files) located in the same directory as WebKit and kdevelop, takes 3 ms on average. Closing a project that has a projectPath with a number of segments unequal to that of WebKit and kdevelop takes 1 ms. Neither of the QSet approaches described above depend on the number of segments in projectPath. Both 3 ms and 1 ms turned into 148 ms on average with one QSet and into 92 ms on average with a vector of QSets. These costs can add up and cause a one second slowdown on each KDevelop exit. And a simple QSet implementation wouldn't even make overlapping projects work right. In addition, the projectPath of a not-removed ProjectFile has to be replaced with the still open project's path that contains it. And if there are still multiple such open projects, which one to choose? Until there is a convincing use case or a legitimate workflow that suffers from this bug, I don't want to sacrifice performance for a fix. -- You are receiving this mail because: You are watching all bug changes.
