In commit 7307 the ProjectDirTraverser was introducued, it should fiyx a problem with cmake generated projects, because they always have "/" as common toplevel path.
This leads to a long delay if the project is loaded, because the codecompletion-plugin checks the whole harddisk for includes.
See:
http://forums.codeblocks.org/index.php/topic,15023.msg100822.html#msg100822The commit had an error and leads to a toplevel path, that was different to the toplevel path calculated in older revisions, and therefore leads to an incorrect layout, if the projectfile was in a folder below it.
http://forums.codeblocks.org/index.php/topic,15023.msg101286.html#msg101286I thought the issue is fixed and it's all good now.
But we got reports about very slow loading of large projects due to the ProjectDirTraverser:
http://forums.codeblocks.org/index.php/topic,15423.msg103528.html#msg103528I looked into it deeper and what I found is, that it seems nobody really thought about the previous two commits.
In my opinion, we should switch back to the way we didi it before the ProjectDirTraverser was introduced, because as far as I know, it has always worked correct.
For the cmake-generated projects "/" is the correct toplevel path for all project files, because cmake puts files below
/usr/src into the project, if the user has it's own files below
/home/username, the common toplevelpath is in fact "/".
And if that's slows down codecompletion, it's not a bug of cc or C::b but of cmake.
And thirdparty bugs should be fixed there and not by changing our software.
I tried the 7307 changes without the DirTraverser and got the same results.
The only thing needed was to forbid a common toplevel path that has no subdirs:
if (tmpbaseF.GetDirCount() && tmpbaseF.GetDirCount() < base.GetDirCount())
This would surely speedup the loadtime a lot, but it would still be incorrect for some projects (like the cmake projects), so the former behaviour would be the best.
What we could do is check whether the drive letter is the same for a projects-file and the base-path (not common toplevel path) of a project, and only use files on the same drive for calculating.
That's only a windows problem and only in the unusual case, that users have a project with files on different drives, but it can surely happen.
I attach a patch, that also checks the volume (aka as drive-letter) and measures the time needed for CalculateCommonToplevelPath.
The stopwatch part is just to see whether it increasye the speed for the large projects and would be completeley removed before a possible commit.
Please test and give feedback.
Note the delay due to cc parsing the whole harddisk is there again, but as said before it should be fixed by cmake, or probably handled by cc itself, but it should not break the way the common toplevel path is calculated.
