Author Topic: CodeCompletion slow on some machine  (Read 32972 times)

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
CodeCompletion slow on some machine
« on: April 10, 2012, 09:34:53 pm »
I have a slowness problem with CodeCompletion.
The exact problem is as follow:
  - the problem appear only on 1 machine (Windows XP 32 bits 2007 SP3, CB SVN build 7925, at work)
    It does not appear on my own laptop (Windows 7 64 bits,  CB SVN build 7925). Both config have approximately same hardware configuration (1 year laptop, powerful enough for running CAD softwares).

  - slow loading of workspace. I have a workspace consisting of 23 projects. Each projects has between 10 and 550 files (total : 1600 files approximately, counting .h files)
    On my work computer, the project loads 10 times slower when CodeCompletion is activated (measured : 1 minute against 10 minutes roughly)

  - when editing a project file, the IDE freezes for 1 to 5 minutes (again, only on the work computer, with XP). What I mean with editing is : open a file (new tab in the wxAUI notebook), and activate it by clicking with the mouse. This is the most annoying bug.

  - This problem did not happen in the Debugger Branch, until the recent merge with trunk.

I have tryied to debug the CodeCompletion plugin using instructions on the Wiki (Ctrl + Shift + "debug SmartSense"), but it did not help a lot (or I do not know what to look for in the log).

  I am willing to compile a special version of the CodeCompletion plugin and try it at work, to know where is the problem (and possibly correct it). Basically, I want to add some debugging message and timers information in the debug log.

  Can someone help me in identifying the hot spots in the plugin ? Where should I start to look for possible candidates ?

Seb

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: CodeCompletion slow on some machine
« Reply #1 on: April 10, 2012, 09:41:28 pm »
Can someone help me in identifying the hot spots in the plugin ? Where should I start to look for possible candidates ?
Can you first try what happens if you disable the ToDo list plugin (yes: ToDo)?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
Re: CodeCompletion slow on some machine
« Reply #2 on: April 11, 2012, 08:58:13 pm »
Can someone help me in identifying the hot spots in the plugin ? Where should I start to look for possible candidates ?
Can you first try what happens if you disable the ToDo list plugin (yes: ToDo)?

I have tried that, and unfortunately it did not help.
I have tried to measure the code speed on my laptop at work : I have found a few solutions, although it is not perfect.

BUG 1 : loading a workspace is 10 times slower on Win XP than on Win 7 (laptop on WinXP is an Intel Core I7, laptop on Win7 64 is an Intel Core I5)
  => most of the time is spent in the method NativeParser::AddCompilerDirs.

More specifically : it seems to be in these following pieces of code:

Code
// get targets include dirs
    for (int i = 0; i < project->GetBuildTargetsCount(); ++i)
    {
        ProjectBuildTarget* target = project->GetBuildTarget(i);
        if (target && target->SupportsCurrentPlatform())
        {
            if (compiler)
            {
                // post-processed search dirs (from build scripts)
                for (unsigned int ti = 0; ti < compiler->GetCompilerSearchDirs(target).GetCount(); ++ti)
                {
                    wxString out = compiler->GetCompilerSearchDirs(target)[ti];
                    wxFileName dir(out);
                    if (NormalizePath(dir, base))
                    {
                        parser->AddIncludeDir(dir.GetFullPath());
                        TRACE(_T("AddCompilerDirs() : Adding compiler target dir to parser: ") + dir.GetFullPath());
                    }
                    else
                        CCLogger::Get()->DebugLog(F(_T("Error normalizing path: '%s' from '%s'"), out.wx_str(), base.wx_str()));
                }
            }

            // apply target vars
//            target->GetCustomVars().ApplyVarsToEnvironment();
            for (unsigned int ti = 0; ti < target->GetIncludeDirs().GetCount(); ++ti)
            {
                wxString out = target->GetIncludeDirs()[ti];
//                Manager::Get()->GetMacrosManager()->ReplaceMacros(out);
                wxFileName dir(out);
                if (NormalizePath(dir, base))
                {
                    parser->AddIncludeDir(dir.GetFullPath());
                    TRACE(_T("AddCompilerDirs() : Adding target dir to parser: ") + dir.GetFullPath());
                }
                else
                    CCLogger::Get()->DebugLog(F(_T("Error normalizing path: '%s' from '%s'"), out.wx_str(), base.wx_str()));
            }
            // get the compiler
            wxString CompilerIndex = target->GetCompilerID();
            Compiler* tgtCompiler = CompilerFactory::GetCompiler(CompilerIndex);
            if (tgtCompiler)
            {
                Compilers[nCompilers] = tgtCompiler;
                ++nCompilers;
            }
        } // if (target)
    } // end loop over the targets

    // add compiler include dirs
    for (int idxCompiler = 0; idxCompiler < nCompilers; ++idxCompiler)
    {
        const wxArrayString& dirs = (Compilers[idxCompiler])->GetIncludeDirs();
        for (unsigned int i = 0; i < dirs.GetCount(); ++i)
        {
//            CCLogger::Get()->Log(mltDevDebug, "Adding %s", dirs[i].c_str());
            wxString out = dirs[i];
            Manager::Get()->GetMacrosManager()->ReplaceMacros(out);
            wxFileName dir(out);
            if (NormalizePath(dir,base))
            {
                parser->AddIncludeDir(dir.GetFullPath());
                TRACE(_T("AddCompilerDirs() : Adding compiler dir to parser: ") + dir.GetFullPath());
            }
            else
                CCLogger::Get()->DebugLog(F(_T("Error normalizing path: '%s' from '%s'"), out.wx_str(), base.wx_str()));
        }

        // find out which compiler, if gnu, do the special trick
        // to find it's internal include paths
        // but do only once per C::B session, thus cache for later calls
        wxString CompilerID = (Compilers[idxCompiler])->GetID();
        if (CompilerID.Contains(_T("gcc")))
            AddGCCCompilerDirs(Compilers[idxCompiler], parser);
    } // end of while loop over the found compilers

(code for finding the compiler and target include directories, and compute full-path from that).


So I have optimized a bit this method :
    1 - cache loop boundaries (no need to call each loop GetCount()). I know it is probably not significant, but just for testing
    2 - Optimize ParserBase::AddIncludeDir : there is a call here to wxArrayString::Index, which is linear (O(n)). I have added a HashSet for string (available in wxWidgets)
    3 - clean up the code : there is 3 times the same code to do: fetch include dir, do macro expansion, normalize the path, add to include dir list. I have moved this code inside a new method ParserBase::AddIncludeDirFast, and commented out the previous code
    4 - there is probably some other optimisations to perform : there is a lot of wxString copy overall.

I attach a patch with :
    - the modifications discussed above
    - some additional debugging code in NativeParser.cpp and codecompletion.cpp (can be deactivated).
   

Applying the patch above helped a lot... at first. After 1 hour, the slow behaviour resumed, so there must be another bottleneck somewhere.


BUG 2 : same freezing behaviour, but I can reproduce it at will now. Use case is as follow:
    - large workspace, with several projects
    - project A is active
    - open a file from another project (not from the active project) => freeze for 2 to 6 minutes observed.

Debug logs pointed out to NativeParser::AddCompilerDirs again. The patch above solved this problem as well - for 1 hour...

I am sorry if I could not find out more - after a while, I had to resume what I should have been doing at work : working. I will try again when possible

Regards,

Seb

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeCompletion slow on some machine
« Reply #3 on: April 12, 2012, 04:12:53 am »
I see you add some profile timers, that's nice, I will test it. I sometimes experience that lag problem I'm editing, about 2-3 seconds, at that time, the whole editor locks.

BTW:
There are many linear searches in function like:
Code
cbProject* NativeParser::GetProjectByFilename(const wxString& filename)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
Re: CodeCompletion slow on some machine
« Reply #4 on: April 12, 2012, 10:50:24 pm »
I see you add some profile timers, that's nice, I will test it. I sometimes experience that lag problem I'm editing, about 2-3 seconds, at that time, the whole editor locks.

BTW:
There are many linear searches in function like:
Code
cbProject* NativeParser::GetProjectByFilename(const wxString& filename)


You are right - I have just tried what is obvious first.

Today, I have done more tests :
  - keep only CodeCompletion and Compiler plugin (physical delete of all the other plugins) => the lag still persists => this is not due to some complex interaction with another plugin
  - I have tried to compile the codecompletion code from the last debugger branch on the last trunk nightly => I still get the block
     The same code on the Debugger branch does not block at all (7 seconds to open my workspace, agains 140 seconds with the last nightly + same code-completion code) => there is a deep change somewhere in the code::blocks codebase which provokes the slow behaviour
  - why does it blocks on Win XP and not on Win 7 ? This is perhaps thread related, but it is a very wild guess.
  - when I omit to normalize the path of the include directories (no call to wxFileName::Normalize in NativeParser::AddCompilerDirs), I do not get the blocking behaviour. (this can perhaps help to diagnose the cause of the problem).
  - all the time is spent in the method NativeParser::AddCompilerDirs (140 seconds on 141). Skipping this method resolves the blocking behaviour (but less includes directories are parsed, so there are less risk of blocking)
  - same blocking behaviour happens with other workspaces (CodeBlocks contrib plugins).

I will try to compile the code-completion plugin with older code::blocks version, to see if the blocking behaviour has been triggered by a specific version. Be patient, because it will take some time...

Truth to be said, I am a bit lost currently, because I do not know how the plugin works. I can read the source, of course, but it takes time. Currently, I work with the last debugger nightly.

Seb

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeCompletion slow on some machine
« Reply #5 on: April 13, 2012, 03:02:54 am »
  - when I omit to normalize the path of the include directories (no call to wxFileName::Normalize in NativeParser::AddCompilerDirs), I do not get the blocking behaviour. (this can perhaps help to diagnose the cause of the problem).
  - all the time is spent in the method NativeParser::AddCompilerDirs (140 seconds on 141). Skipping this method resolves the blocking behaviour (but less includes directories are parsed, so there are less risk of blocking)

Do you mean this one in globals.cpp
Code
bool NormalizePath(wxFileName& f,const wxString& base)
{
    bool result = true;
//    if (!f.IsAbsolute())
    {
        f.Normalize(wxPATH_NORM_ALL & ~wxPATH_NORM_CASE, base);
        result = f.IsOk();
    }
    return result;
}

Quote
Truth to be said, I am a bit lost currently, because I do not know how the plugin works. I can read the source, of course, but it takes time. Currently, I work with the last debugger nightly.
The CodeCompletion plugin wiki page may give you some hints:
http://wiki.codeblocks.org/index.php?title=Code_Completion_Design

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
Re: CodeCompletion slow on some machine
« Reply #6 on: April 13, 2012, 07:53:28 pm »
Do you mean this one in globals.cpp
Code
bool NormalizePath(wxFileName& f,const wxString& base)
{
    bool result = true;
//    if (!f.IsAbsolute())
    {
        f.Normalize(wxPATH_NORM_ALL & ~wxPATH_NORM_CASE, base);
        result = f.IsOk();
    }
    return result;
}

Yes, exactly. I have moved all the steps from the NativeParser::AddCompilerDirs() method into a new method Parter::AddIncludeDirFast. (steps are : macro expansion, path normalization, check directory existence, add directory to list). It made the NativeParser::AddCompilerDirs() method more readable for me.

Quote
Quote
Truth to be said, I am a bit lost currently, because I do not know how the plugin works. I can read the source, of course, but it takes time. Currently, I work with the last debugger nightly.
The CodeCompletion plugin wiki page may give you some hints:
http://wiki.codeblocks.org/index.php?title=Code_Completion_Design

I have seen the wiki, but I did not have the time to read it carefully : I am a bit new regarding all parsing algorithm theory, and true understanding would take some time. I will do it in due time, but first I wanted to see if it was possible to identify an obvious bottleneck, and to correct it.

Seb

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeCompletion slow on some machine
« Reply #7 on: April 14, 2012, 03:26:12 am »
I believe that you code have some encoding problems, see the log when I set the debug log output:
Quote
Start : OnEditorClosed
End : 湏摅瑩牯汃獯摥. Done in 0 ms.
Start : OnEditorActivated
End : 湏摅瑩牯捁楴慶整d. Done in 0 ms.
Start : OnEditorOpen
End : 湏摅瑩牯灏湥. Done in 0 ms.
Start : OnEditorActivated
End : 湏摅瑩牯捁楴慶整d. Done in 0 ms.
Start : OnEditorActivated
End : 湏摅瑩牯捁楴慶整d. Done in 0 ms.
Start : OnWorkspaceChanged
End : 湏潗歲灳捡䍥慨杮摥. Done in 0 ms.
Start : OnProjectActivated
湏牐橯捥䅴瑣癩瑡摥㨠匠整⁰1. Done in 0 ms.
Start : NativeParser::CreateParser
慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰1Full parsing failed!. Done in 0 ms.
Start : NativeParser::DoFullParsing
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥ㄠ. Done in 0 ms.
Start : NativeParser::AddCompilerDirs
慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物⁳›瑳灥ㄠ. Done in 0 ms.
慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物⁳›瑳灥㈠. Done in 219 ms.
慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物⁳›瑳灥㌠. Done in 219 ms.
慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物⁳›瑳灥㐠. Done in 219 ms.
慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物⁳›瑳灥㔠. Done in 375 ms.
慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物⁳›瑳灥㘠. Done in 375 ms.
Start : ParseFunctionsAndFillToolbar
End : 慐獲䙥湵瑣潩獮湁䙤汩呬潯扬牡. Done in 0 ms.
Caching GCC dir: E:\code\gcc\mypcxmingw463\lib\gcc\i686-w64-mingw32\4.6.3\include\c++
Caching GCC dir: E:\code\gcc\mypcxmingw463\lib\gcc\i686-w64-mingw32\4.6.3\include\c++\i686-w64-mingw32
Caching GCC dir: E:\code\gcc\mypcxmingw463\lib\gcc\i686-w64-mingw32\4.6.3\include\c++\backward
Caching GCC dir: E:\code\gcc\mypcxmingw463\lib\gcc\i686-w64-mingw32\4.6.3\include
Caching GCC dir: E:\code\gcc\mypcxmingw463\include
Caching GCC dir: E:\code\gcc\mypcxmingw463\lib\gcc\i686-w64-mingw32\4.6.3\include-fixed
Caching GCC dir: E:\code\gcc\mypcxmingw463\i686-w64-mingw32\include
慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物⁳›瑳灥㜠. Done in 1734 ms.
End : 慎楴敶慐獲牥㨺摁䍤浯楰敬䑲物s. Done in 1734 ms.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㈠. Done in 1734 ms.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㌠. Done in 1859 ms.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㐠. Done in 1859 ms.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㔠. Done in 1859 ms.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㘠. Done in 1859 ms.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㜠. Done in 2359 ms.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㜠. Done in 2391 ms.
Passing list of files to batch-parser.
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㠠. Done in 2391 ms.
Header to parse with priority: 'E:\code\gcc\mypcxmingw463\lib\gcc\i686-w64-mingw32\4.6.3\include\c++\cstddef'
Header to parse with priority: 'E:\code\gcc\mypcxmingw463\i686-w64-mingw32\include\w32api.h'
Header to parse with priority: 'E:\code\cb\cb_debugger_branch\src\include\sdk.h'
Add 3 priority parsing file(s) for project 'Code::Blocks wx2.8.x'...
慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›瑳灥㤠. Done in 2391 ms.
Added 816 file(s) for project 'Code::Blocks wx2.8.x' to batch-parser...
End : 慎楴敶慐獲牥㨺潄畆汬慐獲湩g慎楴敶慐獲牥㨺潄畆汬慐獲湩⁧›潮瀠牡敳rNativeParser::DoFullParsing(). Done in 2391 ms.
慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰2慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰3慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰4*NONE*. Done in 2391 ms.
慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰3慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰4*NONE*. Done in 2422 ms.
慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰4*NONE*. Done in 2422 ms.
Create new parser for project 'Code::Blocks wx2.8.x'
慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰5慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰6Parser does not exist for delete '%s'!. Done in 2422 ms.
慎楴敶慐獲牥㨺牃慥整慐獲牥㨠猠整⁰6Parser does not exist for delete '%s'!. Done in 2422 ms.
湏牐橯捥䅴瑣癩瑡摥㨠匠整⁰2湏牐橯捥䅴瑣癩瑡摥㨠匠整⁰3. Done in 2422 ms.
湏牐橯捥䅴瑣癩瑡摥㨠匠整⁰3. Done in 2422 ms.
End : 湏牐橯捥䅴瑣癩瑡摥伀偮潲敪瑣捁楴慶整⁤›瑓灥ㄠ. Done in 2422 ms.
Updating class browser...
Class browser updated.
Starting batch parsing for project 'Code::Blocks wx2.8.x'...
Start : OnParserStart
End : 湏慐獲牥瑓牡tOnParserEnd. Done in 0 ms.
Project 'Code::Blocks wx2.8.x' parsing stage done!
Project 'Code::Blocks wx2.8.x' parsing stage done (1079 total parsed files, 84540 tokens in 0 minute(s), 58.641 seconds).
Start : OnParserEnd
End : 湏慐獲牥湅d. Done in 0 ms.
Updating class browser...
Start : ParseFunctionsAndFillToolbar
End : 慐獲䙥湵瑣潩獮湁䙤汩呬潯扬牡. Done in 15 ms.
Class browser updated.
Start : OnEditorActivated
End : 湏摅瑩牯捁楴慶整d. Done in 0 ms.
Start : OnEditorActivatedTimer
湏摅瑩牯捁楴慶整呤浩牥搠潮桴湩g. Done in 0 ms.
I'm using WinXP (my local language is Chinese), So I think the _T() is need like:
Code
CC_TRACE_FILE_END(_T("CodeComplete"));
right?
« Last Edit: April 14, 2012, 03:29:36 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeCompletion slow on some machine
« Reply #8 on: April 14, 2012, 05:19:17 am »
Look:
Code
#define CC_TRACE_LOG_START(x)                                               \
        wxString sStart(_T("Start : "));                                        \
        sStart += _T(x);                                                        \
        CCLogger::Get()->DebugLog(sStart);                                      \
        std::ofstream os("debug_cc.txt",                                        \
                         std::ios_base::app | std::ios_base::out);              \
        os << "Start : " << x << std::endl;
So, _T(x) is here.

Code
#define CC_TRACE_LOG_END(x, y)                                              \
        wxString sEnd;                                                          \
        sEnd.Printf(_T("End : %s. Done in %d ms."),x, y);                       \
        CCLogger::Get()->DebugLog(sEnd);                                        \
        os << "End : " << x << " done in " << y << " ms."  << std::endl;
It should be:
Code
sEnd.Printf(_T("End : %s. Done in %d ms."),_T(x), y); 
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeCompletion slow on some machine
« Reply #9 on: April 14, 2012, 05:48:56 am »
BTW: How can I test it, I have apply your patch, and I just use the c::b to open codeblocks.cbp, I can't see difference in the time when CC parsing stage done.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: CodeCompletion slow on some machine
« Reply #10 on: April 15, 2012, 01:13:52 pm »
I attach a patch with :
    - the modifications discussed above
    - some additional debugging code in NativeParser.cpp and codecompletion.cpp (can be deactivated).
Please remove the additional debugging from bug fixes. It is hard to maintain/follow otherwise. And also remove large portions of commented code. If you want us to follow your steps you shouldn't provide patches where 90% of it is actually not related to fixing a bug. ???
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeCompletion slow on some machine
« Reply #11 on: April 15, 2012, 03:37:40 pm »
@morten
The debug code in this patch can help us to profile the CC code. :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: CodeCompletion slow on some machine
« Reply #12 on: April 15, 2012, 03:38:39 pm »
@morten
The debug code in this patch can help us to profile the CC code. :)
I guess using the profiler plugin and a testing environment you can do much better ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CodeCompletion slow on some machine
« Reply #13 on: April 15, 2012, 03:42:23 pm »
@morten
The debug code in this patch can help us to profile the CC code. :)
I guess using the profiler plugin and a testing environment you can do much better ;-)
If I remember correctly, I did that and we also have discussion in our forum.
I once use profile plugin(basically use gcc pg options) to analysis CC code, but that was a bit mass report under Windows, I can't find much useful information.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
Re: CodeCompletion slow on some machine
« Reply #14 on: April 15, 2012, 04:44:43 pm »
@OllyDbg:
regarding the encoding problem: I have the same problem on a my computer. I believe it has something to do with the wxString::Printf %s format specifier, and your suggestion to add _T() is probably correct. I will correct the code.

@Morten
for the patch, it is not so easy to separate, because all the changes are located in 2 files. My SVN client (TortoiseSVN) does not allow me to select which changes in 1 file to use for the patch (or I do not know how to do it). The alternative would be to edit the patch manually, but it is error-prone
That beeing said, I totally agree with you : it would be better to provide 2 patches : one for the additionnal profiling, and one for the code change.
I will remove also the commented code. And I will post another patch, with hopefully a real fix.

Regarding the use of a profiler : I will try to use gprof and see if I get something useful out of it. I will do that on the last nightly, with just compiler and codecompletion activated. From my experience, a profiler is helpful with a code that you know. In the case of codeblocks, it will take me some time to just analyze the output of the profiler. This is mainly why I have tried to use manual targeted profiling. If the bottleneck is obvious, you can find it very quickly.
CB is not compiled with the compiler option -pg, correct ? I will need to recompile it.

Regarding the problem
it is apparently related to a code change in CB, and not in the CodeCompletion plugin (since same CodeCompletion code triggers the problem on last nightly, but not on the last debugger branch). It is perhaps thread related, perhaps not.

And please be patient : I can debug this problem only at work, and I have since more than 1 year a very high pressure on my project (reason why other projects seem abandonned, like the xpmeditor). I cannot afford to spend too much time in a row on this problem. I hope everybody can understand that.

Seb
« Last Edit: April 15, 2012, 04:46:15 pm by seb_seb0 »