m_TopNameSpaces in TokensTree class seems useless

[ollydbg]

@all

When reviewing the code of token class, I found that: m_TopNameSpaces is not needed any more.

If you search the member variable "m_TopNameSpaces" usage by ThreadSearch, you will notice that no one use it.

So, shall we just delete this un-used variable?

It is declared in: token.h line 285.

[ollydbg]

Also, this variable

Code Select Expand

m_Modified

is only used when we need to cache the tokens to hard-disk.

Code Select Expand


bool Parser::CacheNeedsUpdate()
{
    if (m_UsingCache)
    {
        wxCriticalSectionLocker locker(s_TokensTreeCritical);
        return m_TokensTree->m_Modified;
    }
    return true;
}


But, In-fact we don't use cache at all, so should be removed too.

[MortenMacFly]

But, In-fact we don't use cache at all, so should be removed too.

After a short discussion about if we need the cache at all anymore I'd say if this turns out to be of no use anymore we should rather remove the whole cache facility, not only this variable. Otherwise caching is broken.

[ollydbg]

agreed.

The cache was too big(eg. the codeblocks.cbp should have 100M memory size) to save to hard disk.

So, I think we don't need cache persistent facility anymore.

[MortenMacFly]

The cache was too big(eg. the codeblocks.cbp should have 100M memory size) to save to hard disk.

The case wasn't saved to the project file abut another (binary based) file. So the size would not be an issue. The question is if we need this to improve speed of scanning through large projects...

[ironhead]

The cache was too big(eg. the codeblocks.cbp should have 100M memory size) to save to hard disk.

The case wasn't saved to the project file abut another (binary based) file. So the size would not be an issue. The question is if we need this to improve speed of scanning through large projects...

To that end, wouldn't it make sense to use the cache on project startup (i.e. load the file cache into memory) versus parsing all the project files again?  Perhaps this would improve the initial project parsing time?

[Loaden]

The cache was too big(eg. the codeblocks.cbp should have 100M memory size) to save to hard disk.

The question is if we need this to improve speed of scanning through large projects...

But we need more IO(read/write) time, when save to hard disk, we need loop the whole tree, their need more time.
So, I personally think this is not needed.

[MortenMacFly]

So, I personally think this is not needed.

I personally believe it would only make sense for system headers, like STL, BOOST or alike. Or simply the compiler's include path would be something where a cache might e useful.

Besides that I see no use, indeed.