The 24 April 2022 build (12802) is out.

[Khram]

Very strong braking when executing a program in the CodeBlocks shell environment. In this case, there is a strong influence on the timers for organizing real-time calculations. Perhaps the latter circumstance leads to damage to large arrays inside the executable program, too.

Please, tell me, is it possible to disable the influence of CodeBlocks on the debug execution time of the program inside it?

Весьма сильное торможение при исполнении программы в среде оболочки CodeBlocks. При это происходит сильное влияние на таймеры для организации вычислений в реальном времени. Возможно последнее обстоятельство приводит к порче больших массивов внутри исполняемой программы, тоже.

Пожалуйста, подскажите, можно ли отключать влияние CodeBlocks на время отладочного исполнения программы внутри него?

[BlueHazzard]

Codeblocks has only influence on the debugee when you set a breakpoint or when you have many watches, memory windows open.
Less watches, less data to transfer, less impact... Also codeblocks adds only overhead if your program actually stops on a breakpoint. If your program runs, codeblocks does not add any overhead.

The rest of overhead you are experiencing comes from gdb.
GDB on windows is really slow, see this: https://stackoverflow.com/questions/27380443/why-is-gdb-so-slow-in-windows
So linux user have a better experience here. On linux the overhead should be fairly small, expect you are using some conditional breakpoints...

What operating system are you using?

[Khram]

Thank you, sincerely. Yes, always have many open windows in CodeBlocks. Need to debug programs in full speed optimization mode. Errors in the computational experiment appear after a very long time of observation of the results.

Unfortunately, CodeBlocks executes programs much more slowly than if it were to run outside of this shell. For real-time execution, this is essential.

Thank you again, so be it.

Благодарю, искренне. У меня всегда много открытых окон в CodeBlocks. Мне приходится  отлаживать программы в режиме полной оптимизации по скорости выполнения. Погрешности в вычислительном эксперименте проявляются после весьма длительного времени наблюдения результатов.

К сожалению CodeBlocks исполняет программы значительно медленнее, чем если бы работать вне этой оболочки. Для исполнения в реальном времени это существенно.

Благодарю, еще раз, пусть так и будет.

[stahta01]

Thank you, sincerely. Yes, always have many open windows in CodeBlocks. Need to debug programs in full speed optimization mode. Errors in the computational experiment appear after a very long time of observation of the results.

Unfortunately, CodeBlocks executes programs much more slowly than if it were to run outside of this shell. For real-time execution, this is essential.

Thank you again, so be it.

And, what is the the operating system you are using?

If you fail to answer the only reasons are you do not understand the question or you are a help vampire!

Tim S.

[BlueHazzard]

Yes, always have many open windows in CodeBlocks

Normal windows (like code editors) do not influence the debugger performance. Only windows from the menu Debug->debugging windows influence the performance.

But as I said... The thing that makes your application slow is gdb, and that probably because you are using windows... Nothing to do with codeblocks....

[Khram]

Without GDB, and only full optimization for speed. OS in Windows-11.

[BlueHazzard]

So have you tried to set the environment variable as described in https://stackoverflow.com/questions/27380443/why-is-gdb-so-slow-in-windows ?
Have you tried gdb from the console, without codeblocks? (it should not make any difference)

Other things that can help:
Not more than 4 break points
Do not debug to libraries with debug symbols (this should only slow down initial startup, but not runtime)

try out cdb instead of gdb

I do not know the kind of bug you are huntig, but you can also try to use printf instead of gdb,
if you search for performance bugs, you can try https://github.com/wolfpld/tracy

ecc...

[Khram]

Thank you. Yes, I have debugging done exclusively with cprintf and in OpenGL on two graphics windows, asynchronously. No GDB or CDB debuggers are fundamentally not used. That is, the calculations themselves, as if in the background, and regardless of this, the visualization of two different processes of wave hydrodynamics and hydromechanics of the ship.

What happens: inside CodeBlocks, seven cores are evenly loaded at 45%, the eighth core at 100%. Without CodeBlocks - the experiment is much faster and all eight cores are loaded evenly by about 40%, and, accordingly, the interactive control is more responsive to external control commands.

Thanks for the link: https://github.com/wolfpld/tracy - really very interesting

Благодарю. Да у меня отладка выполняется исключительно с помощью cprintf и в OpenGL на двух графических окнах, асинхронно.  Никакие отладчики GDB или CDB принципиально не используются.  То есть, расчеты сами по себе, как бы в фоновом режиме, и независимо от этого визуализация двух различных процессов гидродинамики волн и гидромеханики корабля.

Что получается: внутри CodeBlocks равномерно загружаются семь ядер на 45%, восьмое ядро на 100%. Без CodeBlocks - эксперимент проходит значительно быстрее и все восемь ядер загружаются равномерно примерно на 40%, и, соответственно, интерактивное управление получается более отзывчивым на внешние команды управления.

Спасибо за ссылку: https://github.com/wolfpld/tracy - реально очень интересно

[Khram]

The general impression is that CodeBlocks itself launches a debugger, such as GDB, which then affects the user program running inside the shell.

Общее впечатление такое, что сам CodeBlocks, запускает отладчик, типа GDB, который затем влияет на исполняемую внутри оболочки пользовательскую программу.

[BlueHazzard]

The general impression is that CodeBlocks itself launches a debugger, such as GDB, which then affects the user program running inside the shell.

Codeblocks starts the application trough gdb if you run it in debug mode (Red Arrow in tool bar, or Debug->Start)
If you run your application with the green arrow in the toolbar or Build->Run no debugger is called.

[damorin]

Hi,

my C:B is locking down once in a while and there is no RPT file created.

Our company setting for Windows 10 is preventing creating file into the "C:\Program Files\CodeBlocks\" unless you're admin.

Possible that is preventing RPT file to be created ?

Thanks,
svn 12802
Windows 10 Entreprise, 21H2
16 GB

[Miguel Gimenez]

It if just locks there will be no report, only crashes create one.

Starting with r12785, C::B will check if the folder containing the executable is writable, and if it is not then it will write the RPT file in the config folder:

Code

%appdata%\Codeblocks

[damorin]

This is making sense, my previous nightly build was 12765.

Thanks.