The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.

[polygon7]

yes, this delay is already present for so time now, I can confirm ;-)

Hi, killerbot, Could you have a trying r6707.
And post the debug log in here?
Thanks!

Revision 6707 works really fast with #include's

// Edit:
include with "

Code Select Expand


Get include file count is 2, use time is 1

include with <

Code Select Expand


Get include file count is 31006, use time is 57


[Loaden]

yes, this delay is already present for so time now, I can confirm ;-)

Hi, killerbot, Could you have a trying r6707.
And post the debug log in here?
Thanks!

Revision 6707 works really fast with #include's

// Edit:
include with "

Code Select Expand


Get include file count is 2, use time is 1

include with <

Code Select Expand


Get include file count is 31006, use time is 57


About the 2~6 sec delay: I think it is wxScintilla issue, not CC.

[killerbot]

#include " --> worked very fast, but several includes missing
#include <  --> still rather slow [and at the start I always have a lot of entries like this : /32/32/32/32/32/32/32....]

[Loaden]

#include " --> worked very fast, but several includes missing
#include <  --> still rather slow [and at the start I always have a lot of entries like this : /32/32/32/32/32/32/32....]

All code in here:

// Do the code completion when we enter:
// #include "| or #include <|
void CodeCompletion::CodeCompleteIncludes()
{
    wxStopWatch sw;

    if (!IsAttached() || !m_InitDone)
        return;

    cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
    if (!ed)
        return;

    const wxString curFile(ed->GetFilename());
    const wxString curPath(wxFileName(curFile).GetPath());
    wxArrayString buildTargets;

    cbProject* project = m_NativeParser.GetProjectByParser(&m_NativeParser.GetParser());
    ProjectFile* pf = project ? project->GetFileByFilename(curFile, false) : 0;
    if (pf)
        buildTargets = pf->buildTargets;

    FileType ft = FileTypeOf(ed->GetShortName());
    if ( ft != ftHeader && ft != ftSource) // only parse source/header files
        return;

    int pos = ed->GetControl()->GetCurrentPos();
    int lineStartPos = ed->GetControl()->PositionFromLine(ed->GetControl()->GetCurrentLine());
    wxString line = ed->GetControl()->GetLine(ed->GetControl()->GetCurrentLine());
    line.Trim();
    if (line.IsEmpty() || !TestIncludeLine(line))
        return;

    bool useSystemHeaders = false;
    int keyPos = line.Find(_T('"'));
    if (keyPos == wxNOT_FOUND)
    {
        useSystemHeaders = true;
        keyPos = line.Find(_T('<'));
    }
    if (keyPos == wxNOT_FOUND || keyPos > pos - lineStartPos)
        return;
    ++keyPos;

    // now, we are after the quote prompt
    wxString filename = line.SubString(keyPos, pos - lineStartPos - keyPos);
    filename.Replace(_T("\\"), _T("/"), true);

    // fill a list of matching files
    StringSet files;

    // #include <|
    if (m_CCSystemHeaderFiles && useSystemHeaders)
    {
        wxCriticalSectionLocker locker(s_HeadersCriticalSection);
        wxArrayString& incDirs = GetSystemIncludeDirs(&m_NativeParser.GetParser(),
                                                      project ? project->GetModified() : true);
        for (size_t i = 0; i < incDirs.GetCount(); ++i)
        {
            SystemHeadersMap::iterator it = m_SystemHeadersMap.find(incDirs);
            if (it != m_SystemHeadersMap.end())
            {
                const StringSet& headers = it->second;
                for (StringSet::iterator it = headers.begin(); it != headers.end(); ++it)
                    files.insert(*it);
            }
        }
    }

    // #include "|
    if (!useSystemHeaders && project)
    {
        const wxArrayString localIncludeDirs = GetLocalIncludeDirs(project, buildTargets);
        for (int i = 0; i < project->GetFilesCount(); ++i)
        {
            ProjectFile* pf = project->GetFile(i);
            if (pf && FileTypeOf(pf->relativeFilename) == ftHeader)
            {
                wxString file = pf->file.GetFullPath();
                if (file.Find(filename) != wxNOT_FOUND)
                {
                    wxString header;
                    for (size_t j = 0; j < localIncludeDirs.GetCount(); ++j)
                    {
                        const wxString& dir = localIncludeDirs[j];
                        if (file.StartsWith(dir))
                        {
                            header = file.Mid(dir.Len());
                            break;
                        }
                    }

                    if (header.IsEmpty())
                    {
                        if (pf->buildTargets != buildTargets)
                            continue;

                        wxFileName fn(file);
                        fn.MakeRelativeTo(curPath);
                        header = fn.GetFullPath();
                    }

                    header.Replace(_T("\\"), _T("/"), true);
                    files.insert(header);
                }
            }
        }
    }

    // popup the auto completion window
    if (!files.empty())
    {
        ed->GetControl()->ClearRegisteredImages();
        ed->GetControl()->AutoCompSetIgnoreCase(false);
        ed->GetControl()->AutoCompSetCancelAtStart(true);
        ed->GetControl()->AutoCompSetFillUps(m_CCFillupChars);
        ed->GetControl()->AutoCompSetChooseSingle(false);
        ed->GetControl()->AutoCompSetAutoHide(true);
        ed->GetControl()->AutoCompSetDropRestOfWord(m_IsAutoPopup ? false : true);
        wxString final;
        GetStringFromSet(final, files, _T(" "));
        final.RemoveLast(); // remove last space
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Get include file count is %d, use time is %d"),
                                                    files.size(), sw.Time()));
        ed->GetControl()->AutoCompShow(pos - lineStartPos - keyPos, final);
    }
}

Almost all of the time is spent in the AutoCompShow call.
This is not a CC problem, but wxScintilla.

[polygon7]

#include " --> worked very fast, but several includes missing
#include <  --> still rather slow [and at the start I always have a lot of entries like this : /32/32/32/32/32/32/32....]

All code in here:
(...)
Almost all of the time is spent in the AutoCompShow call.
This is not a CC problem, but wxScintilla.

Maybe that includes popup should be visible only when user write similar number of letters like
in CC (Editor->CC->Automatically launch when typed # letters) after " or < character and
popup should contain only that items which have the same letters on start as written by user?

Eg.
Editor->CC->Automatically launch when typed # letters is set to 4
and with:

Code Select Expand


#include <cst|

no popup visible

Code Select Expand


#include <cstd

popup visible and should contain: "cstdio" (or if there is another file with cstd prefix then it should be in popup too).

[Loaden]

This problem does not occur in the Windows platform.

[killerbot]

one thing is for sure :

Code Select Expand


#include "


doesn't show any options any more from file present in the project's include paths (no idea with target's include paths)

[oBFusCATed]

This problem does not occur in the Windows platform.

Probably on windows you have far less header files. On linux many softwares install header files in /usr/include

[Jenna]

I just mesured it with wxStopWatch.

There are 22996, that are splitted in tokens by wxStringTokenizer in PlatWX.cpp ListBoxImpl::SetList (caled by ScintillaBase::AutoCompleteStart ), that needs the great amount of time.

Maybe we have to create our own listbox to show the includes ?

[oBFusCATed]

Or limit the number to 500 and to put "To many includes found..." at the top of the list

[Jenna]

More tests:
The problem is not the wxStringTokenizer, but appending the string to the listcontrol.
So limiting the maximal amount, or better kicking in the autocomp-listbox after 2 or more characters (as default, configurable) might be the best solution.

[Loaden]

More tests:
The problem is not the wxStringTokenizer, but appending the string to the listcontrol.
So limiting the maximal amount, or better kicking in the autocomp-listbox after 2 or more characters (as default, configurable) might be the best solution.

Thanks a lot!

[Loaden]

#include " --> worked very fast, but several includes missing
#include <  --> still rather slow [and at the start I always have a lot of entries like this : /32/32/32/32/32/32/32....]

Fixed in r6708.

[killerbot]

I can confirm that

Code Select Expand


#include <

now works fast, and one first has to type a few first characters.

But the

Code Select Expand


#include "

fails for me.

My test project :
simple console project -> the .cbp and main.cpp are in the same directory. The project has some search/include directories added.
But not even one suggestion pops up, even if I start typing parts of the filename of the header to include.

For further testing purposes, I added 2 more files to the same directory where main.cpp is (and the .cbp) : foo.h and bar.h
Also these 2 don't show up in the suggestion list.

Next I added foo.h to the project, from that moment on the include list "foo.h" appears, but not bar.h [I even added the directory where main.cpp and foo/bar.h live as an include directory explicitly].

This is something that used to work, so I guess somewhere there's still a little glitch.

[Loaden]

Next I added foo.h to the project, from that moment on the include list "foo.h" appears, but not bar.h [I even added the directory where main.cpp and foo/bar.h live as an include directory explicitly].

#include "f // appear f****.h
#include "b // appear b****.h
That's right!