Code::Blocks / Tickets / #716 Code::Blocks 17.12 CodeCompletion slows down the editor dramatically

Teodor Petrov - 2018-07-25

What happens if you do file -> save everything after you've modified the settings? Does the setting persist after a restart of codeblocks?

What kind of project do you see the slowdown? Can you reproduce the slowdown with a small sample project?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

hovercrfat-sf - 2018-07-25

File -> save everything doesn't help - settings doesn't persist after a restart of codeblocks - they are always reset to it's default state (e.g. "Update parser when typing" is always on).
The same is true for other Code Completion related settings, e.g. I tested "Display member list in separate tree" on the "Symbol browser" tab - the same behaviour.
This bug is there for yars and it is always reproduceble.
It isn't system or platform specific - tests on Linux with C::B 16.02 gives the same result.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Teodor Petrov - 2018-07-25
  
  Are you able to make other settings to persists between runs of codeblocks?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - hovercrfat-sf - 2018-07-26
    
    Sure, I can. All settings except CC related stored fine.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- bluehazzard - 2018-07-25
  
  I can not reproduce this on windows 7 latest trunk. CC Settings are saved (At least the Update parser when typing option).
  Have you tried to delete (move) the config file?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - hovercrfat-sf - 2018-07-26
    
    I can reproduce the CC-settings persistence problem on any C::B release up to (including) the latest one (17.12), on any machine with any Linux or Windows version and deleting the config file doesn't help. It's easy:
    
    remove codeblocks configuration directory
    
    start codeblocks, select the default compiler and ansver other questions of the configuration wizard (if any)
    
    create new console "Hello, world" project using C::B new project wizard
    
    go to the CC configuration dialog and turn off "Update parser when typing" and "Display member list in separate tree" options
    
    save & close the workspace using any method
    
    restart codeblocks, reopen the same project/workspace as before, verify that "Update parser when typing" and "Display member list in separate tree" options are again on
    
    I didn't try this on the trunk version yet, because I can't build trunk version using the build method described here . The compiler crashes whenever it reaches any source file, where sdk_precomp.h.gch precompiled header involved. I'm using compiler from MinGw version bundled with C::B 17.12 distribuition. Can you reproduce this on Windows 7 (my system is Windows 8.1, 32 bit, 4Gbyte RAM)?
    
    Last edit: hovercrfat-sf 2018-07-26
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - hovercrfat-sf - 2018-07-26
      
      Hurray! I been able to build the codeblocks trunk using CodeBlocks_wx31.cbp project with wx3.1.1. I only had to disable sdk_precomp.h and sdk.h precompiling for that.
      Now I can confirm that CC-settings persistence problem disappeared in the trunk version, at least for wx3.x builds.
      But .. this version lacks the symbol browser pannel altogether!
      Corresponding View manu item still exists, but it says: "The symbol browser is disabled in wx3.x builds. We've done this because it causes crashes."
      Have you plans to retain this very useful facility, or the symbol browser will be dropped forever?
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Teodor Petrov - 2018-07-26
        
        If someone fixes it to be non-crashy it will be re-enabled. The code is still there.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        hovercrfat-sf - 2018-07-26
        
        I can try to do it, but for that I will ask you to grant me a write access to the C::B development repository to be able to create my own branch of code,
        because working with such a huge projects is a pain without a source code version control.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        bluehazzard - 2018-07-26
        
        You can clone one of the git repos out there. The most up do date is probably https://github.com/obfuscated/codeblocks_sf
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Teodor Petrov - 2018-07-27
        
        Heh, not possible and not required. See what bluehazzard told you. :)
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - ollydbg - 2018-07-28
      
      The compiler crashes whenever it reaches any source file, where sdk_precomp.h.gch precompiled header involved.
      
      First, please check the file size of the "sdk_precomp.h.gch", if it is larger than 128M and you also use an old 32 bit Windows GCC version, the compiler will crash. This crash mostly happens you try to build C::B with wx 3.x.
      
      Newer version of GCC(such as the 32bit mingw-w64 gcc) doesn't have such issue.
      
      EDIT:
      
      Hurray! I been able to build the codeblocks trunk using CodeBlocks_wx31.cbp project with wx3.1.1. I only had to disable sdk_precomp.h and sdk.h precompiling for that.
      
      OK, disable the PCH feature is also a workaround.
      
      Last edit: ollydbg 2018-07-28
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - hovercrfat-sf - 2018-07-28
        
        Hello ollydbg! I'm using tdm-gcc v 5.1 distributed in bundle with latest Code::Blocks 17.12. Looks like it already should be considered outdated to build CodeBlocks itself?
        The size of sdk_precomp.h.gch is about 140M.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        ollydbg - 2018-07-28
        
        Hi, hovercrfat, you can look at this commit:
        https://sourceforge.net/p/codeblocks/code/11401/
        And the link mentioned in the commit.
        If you want to build C::B with PCH enabled against wx3.x under Windows, you need a patched GCC. TDM-GCC don't have this patch applied.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- ollydbg - 2018-07-28
  
  This bug is there for yars and it is always reproduceble.
  
  Yes, it is a known bug.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - hovercrfat-sf - 2018-07-28
    
    Sure! And my feeling it is responsible also for memory corruption and weird behaviour described here.
    I want try to fix it, using fork of https://github.com/obfuscated/codeblocks_sf ,as bluehazzard adviced.
    If it would be successfull, can I than attach my future patch to this ticket?
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Teodor Petrov - 2018-07-28
      
      I doubt it is related to any memory corruptions.
      The repo in the link is not a fork. It is my repo and it is the exact same code you get from the official svn repo. I just use git and it easier for me to test stuff.
      
      Patches are always welcome. If you have an idea for a big change it is better to first discuss it, so you don't spend too much time in vein.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - hovercrfat-sf - 2018-07-28
        
        Right, I also like git. Is it Ok if I will create a PR to your github repo?
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        ollydbg - 2018-07-28
        
        Which memory corruption do you have? The slow down issue is related to memory corruption?
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        hovercrfat-sf - 2018-07-28
        
        I think so, because C::B (17.12 release) crashes quite often in particular after I experirnce a slow-down. However, I didn't notice crashes (nor slow-down) on the trunk build, where the symbol browser is disabled completelly.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Teodor Petrov - 2018-07-28
        
        Nope, the main repo is SVN based, so it doesn't support git merges. You can show me your branch or create a textual patch, doesn't matter, too much.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

hovercrfat-sf - 2018-07-25

The slow-down effect is not so easely reproduceble: it may manifest itself on any kind of project, e.g. simplest "Hello world", but may disappear after opening some large project, like C::B self build one.
I noticed however: when the "slowdown" is in effect, the CodeCompletion toolbar reacts as follows:
when I strike some arrow key on my keyboard to move the cursor, function name list in the toolbar is cleared, then editor freezes for 1 second or so, then cursor moves to the new position, function name list refilled and the editor unfreezes.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Teodor Petrov - 2018-07-25
  
  Do you have many (500, 1000, 10000) functions or sturcts/classes in a single file when the slowdown happens? I know about a prolbem related to this and the toolbar.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - hovercrfat-sf - 2018-07-26
    
    No, this can manifest itself on any kind of project, e.g. simplest "Hello world", There is no many (500, 1000, 10000) functions there. I believe this is a result of memory corruption which arise inside the CodeBlocks occasionally (sometimes the IDE crashes in some moment afterward).
    It's highly likely that the reason of corruption is the buggy CodeCompletion config manager class in the C::B.
    
    Last edit: hovercrfat-sf 2018-07-26
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Teodor Petrov - 2018-07-26
      
      I doubt it is the "buggy" config manager class. High memory consumption happens sometimes when the include scanner starts to traverse the whole disk (at least on linux). There are fixes for this in trunk.
      
      Are you able to reproduce the slowness with the trunk version?
      When the slowness happens can you attach a debugger and try to stop the executable during moments of sluggishness?
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Code::Blocks 17.12 CodeCompletion slows down the editor dramatically

A free C, C++ and Fortran IDE

Milestone

Searches

Help

#716 Code::Blocks 17.12 CodeCompletion slows down the editor dramatically

Discussion