User forums > Using Code::Blocks
Bug Report: [#18755] C::B hangs for 20 seconds while opening large project...
dmoore:
--- Quote from: rickg22 on November 03, 2012, 06:51:38 pm ---
--- Quote from: dmoore on November 03, 2012, 06:31:22 pm ---
Even if we do use the cache, it would make sense to use the logic to create the path (and add it to the cache) when there are cache missses to reduce the number of MakeRelativeTo calls.
--- End quote ---
Yes, that's exactly what the cache does.
--- End quote ---
Sorry, wasn't clear. What I meant was whenever you have a cache miss, instead of using MakeRelativeTo in all cases, use the faster method when possible.
rickg22:
--- Quote from: dmoore on November 03, 2012, 07:12:49 pm ---
Sorry, wasn't clear. What I meant was whenever you have a cache miss, instead of using MakeRelativeTo in all cases, use the faster method when possible.
--- End quote ---
Ah, my apologies. I forgot to explain how my Cache works, and what I consider a "cache miss".
It's not really a full path cache; it's a PARENT PATH Cache. And it's recursive :D
Let's say that your filename has a full path + name like this:
C:\myProjects\myProject1\src\plugins\myplugin\includes\myheader.h
What my cache does is searching first for the parent path, and if it doesn't find it, go to its own parent path, and so on, like this:
--- Code: ---C:\myProjects\myProject1\src\plugins\myplugin\includes
C:\myProjects\myProject1\src\plugins\myplugin
C:\myProjects\myProject1\src\plugins
C:\myProjects\myProject1\src
C:\myProjects\myProject1
--- End code ---
At that point, C:\myProjects\myProject1 is actually our project common top level path. So it's found (which is not considered a cache miss, because we can construct the relative path without resorting to wxFilename's functions). Then, as the cache returns from its call stack, adds the items in the reverse order in which they were searched:
--- Code: ---C:\myProjects\myProject1\src => src
C:\myProjects\myProject1\src\plugins => src\plugins
C:\myProjects\myProject1\src\plugins\myplugin => src\plugins\myplugin
C:\myProjects\myProject1\src\plugins\myplugin\includes => src\plugins\myplugin\includes
C:\myProjects\myProject1\src\plugins\myplugin\includes\myheader.h => src\plugins\myplugin\includes\myheader.h (not added to the cache, just calculated)
--- End code ---
The actual filename, C:\myProjects\myProject1\src\plugins\myplugin\includes\myheader.h is never added to the cache, because it will only be requested ONCE. However,
--- Code: ---C:\myProjects\myProject1\src\plugins\myplugin\includes\myheader2.h
C:\myProjects\myProject1\src\plugins\myplugin\includes\myheader3.h
C:\myProjects\myProject1\src\plugins\myplugin\includes\myheader4.h
--- End code ---
WILL be requested. Their common denominator is their path, which is already cached. And so are their parent directories.
This means that at most, ONE cache miss will be present: The project's common top level path itself, but that's already added by default! 8)
The real cache misses will be files outside the project's common top level path, which require using wxFilename anyway, so they're not added to the cache. BUT I might add them, I just wasn't sure if adding them would trigger some misbehavior in the cache...
rickg22:
I just realized something.
With minor modifications to my cache's constructor, we can add all the parent paths from the project's CTLP to the root directory, and we will cover ALL cases!
--- Code: ---C:\projects\myProject1 => ''
C:\projects => '..'
C:\ => '..\..'
--- End code ---
which means that
--- Code: ---C:\somepathoutside\someotherpath\whatever\myexternalfile.cpp => ..\..\somepathoutside\someotherpath\whatever\myexternalfile.cpp
--- End code ---
At this point, using wxFilename won't be necessary because it's already certain that the file we're searching for and our project reside in the same unit (that's the big "if" that was added in the latest SVN, for cases with different units, the absolute paths are added verbatim). And since they're in the same unit, we have no cache misses AT ALL! For ANY FILE, either inside or outside our CTLP.
(The only caveat is if we have a symlink circular reference around... I'd need to think about how to solve that)
rickg22:
OK, I'm adding a *disabled* version of the path cache to trunk (to enable it, you have to #define use_path_cache_for_ctlp). I moved the path cache code to a separate file, so the code changes can be more obvious.
I'm also adding the "check for missing files" option.
Should I commit, or just post another patch? The code's ready.
MortenMacFly:
--- Quote from: rickg22 on November 04, 2012, 02:32:49 am ---Should I commit, or just post another patch? The code's ready.
--- End quote ---
It is tested against UNC path's again and also against different project tree layout options?
BTW: I had a few days off and I am trying to catch up - what's with the other patches in the other posts of this thread? Does this one cover all?
Oh - and btw: I don't know if I personally would sacrifice the read-only flag for speed. When working with SVN controlled projects its often vital to see if a file is write-protected (i.e. locked). So I would definitely like to see a global option to be able to always have this check on in one place.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version