Author Topic: Codeblocks long startup time (Read 14501 times)

Cappedcrusader12 · « **on:** December 18, 2021, 08:06:34 am »

Hi,
I am new to the forums. I have Codeblocks 20.03 after changing from 17.12 and 16.10 and ever since i changed to 17.12 my startup times tripled in length. I have reinstalled it multiple times, and stil got the same result.
I am using it on a laptop with windows 10 pro, core i7 8750h, 16gb ram and gtx 1060.

AndrewCot · « **Reply #1 on:** December 18, 2021, 08:15:13 am »

What is the startup time and what are the steps / process you are using to measuring it?

Cappedcrusader12 · « **Reply #2 on:** December 18, 2021, 08:16:50 am »

The startup time is about 30 seconds, and I measured it with the stopwatch app on my phone

AndrewCot · « **Reply #3 on:** December 18, 2021, 09:27:53 am »

The nightly 12579 on my PC took 5.34 seconds to start. Using the same process.

My C: is a Samsung 980 pro 1TB SSD, which is very fast and has the OS & dev tools on it, but it does NOT have any source code on it as I do not want to wear it out prematurely due to builds. I also have W10, but it is patched to the latest as is the rest of the apps and AV. I have 32Gb, but 16 to 32 should not affect loading, unless you have other apps chewing up memory. I have a AMD Ryzen 5700G and do not use a separate GPU as I do not play "games" for fun, but for work I do, but lets just say Lost Wages is the game type. Your CPU should be okay.

The 20.03 "flashes" up a dialog when it starts that was fixed in a nightly about 2 or 3 months ago. This may slow your setup and if it is try the latest nightly or if you do not want to install it manually have a read of the https://forums.codeblocks.org/index.php/topic,24592.0.html thread. If after testing the nightly please post how you go and if it is still slow can you check the free ram and how much free space you have on C: as these could possibly affect the load time. The other ting that could also affect load time for the very first time is the AV installed as it will need to scan the files, so check the speed after starting C::B a few times. Another thing to check, which I have not looked at for years is the disk I/O and see if it is the problem.

BTW Reinstalling it in 99.9% of cases does not fix or change things, unless the config or app have become corrupted.

Miguel Gimenez · « **Reply #4 on:** December 18, 2021, 09:46:47 am »

In my system current head (32-bit version) took 3.03 seconds to start, but I only have some plugins enabled.

System: i7 8700K @ 3.7 GHz with SSD

Some antivirus can delay program start many seconds.

Cappedcrusader12 · « **Reply #5 on:** December 18, 2021, 11:33:08 am »

Ok, so i've installed the latest nightly build using the unofficial installer, because I couldn't find the required dlls to make the program work. I still get the same startup time.
I opened the task manager and saw that there was not that much of a resource usage from opening it or the presence of the antivirus. I also installed it on my ssd to see if it would make a change, but it did not(the SSD is 2/3 full).

cacb · « **Reply #6 on:** December 18, 2021, 04:26:02 pm »

I would start disabling unnecessary plugins one by one to see if it is caused by one of them.

I tend to disable many plugins and C::B starts in just a few seconds on both my 10 year old Windows box (Win10) with a SSD system disk and my newer Linux box.

BlueHazzard · « **Reply #7 on:** December 18, 2021, 09:04:07 pm »

Also try to rename your configuration file from C:\User\USERNAME\AppData\Roaming\Codeblocks\default.conf to default.conf.old and see if this speeds things up

Cappedcrusader12 · « **Reply #8 on:** December 19, 2021, 12:27:59 pm »

The renaming of the default.conf file to default.conf.old reduced the time to 10 seconds. Thanks!

Cappedcrusader12 · « **Reply #9 on:** December 19, 2021, 02:30:15 pm »

After restarting, it reverted to the normal time, even if I rename the newly created file.

BlueHazzard · « **Reply #10 on:** December 20, 2021, 12:06:45 pm »

Can you share your conf file?
Are you loading a project?
What compiler do you have installed/Enabled?

Cappedcrusader12 · « **Reply #11 on:** December 20, 2021, 01:10:15 pm »

Here is the conf file.I am not loading any projects, and i only have gnu gcc and ttd installed.

Cappedcrusader12 · « **Reply #12 on:** December 20, 2021, 01:12:15 pm »

not Ttd, but GNU GCC TDM-64

BlueHazzard · « **Reply #13 on:** December 25, 2021, 11:29:46 pm »

Have you tried to deactivate plugins?
I can not find anything special in your config file...

Cappedcrusader12 · « **Reply #14 on:** December 30, 2021, 01:08:01 pm »

I disabled all the plugins and still got the same loading time.

AndrewCot · « **Reply #15 on:** December 31, 2021, 04:27:24 am »

I tried the config file and found that the Cygwin compiler was always shown in the Compilers auto-detection that pops up on start-up as Invalid due to the config not having a <compiler><sets><cygwin> [MASTER_PATH] entry. The C::B I was testing against was SVN r12612 code with the addition of timing output to the log to measure the approximate C::B startup time and the compiler XML files from ticket 374 as I am trying to track down a C::B slow startup issue Miguel seen. Miguel can I get a copy of your config?

After adding in the <compiler><sets><cygwin> [MASTER_PATH] entry I did not see any major slow down in the C::B startup (the XML file changes add an extra 1 second).

Cappedcrusader12 can I get the list of GCC and other compiler's you have installed with their root or bin directory along with what version of the compiler it it. For example:
MSYS2 Mingw64 - C:\msys64\mingw64

I have the following compiler's installed, but I prefix them with "test." when I am not using or testing them:
MSYS2 Mingw64 - C:\msys64
TDM 64 - C:\TDM-GCC-64
TDM 32 C:\TDM-GCC-32
Mingw64 - C:\mingw64
Mingw32 - C:\mingw32
Mingw - C:\MinGW
Mingw64 Guyutongxue C:\mingw64_gtx
Mingw64 WinLib C:\mingw64_winlib
Cygwin - C:\cygwin64

AndrewCot · « **Reply #16 on:** December 31, 2021, 05:32:14 am »

See https://sourceforge.net/p/codeblocks/tickets/1171/ for the Cygwin masterpath ticket and fix.

Still no closer on the startup time issue.

Miguel Gimenez · « **Reply #17 on:** December 31, 2021, 10:59:57 am »

Quote

Miguel can I get a copy of your config?

I am on Xmas vacation, far from my main computer. I'll send it as soon as I return home (ten days).

AndrewCot · « **Reply #18 on:** December 31, 2021, 11:10:09 am »

No worries. I was away last week and this week have eased back into it.

Miguel Gimenez · « **Reply #19 on:** December 31, 2021, 01:36:01 pm »

I have downloaded using Remote Desktop the configuration from my computer at work, it is very similar to that of my home system.

BlueHazzard · « **Reply #20 on:** January 04, 2022, 09:42:43 pm »

@Cappedcrusader12
How good are you with computer?
Are you able to compile codeblocks by yourself?

Can i send you a compiled version of codeblocks with debug symbols? Maybe over WeTransfer?

@AndrewCot Are your builds with debug symbols?

Edit: i should say, that i looked at codeblocks startup with IntelVtune and i can not really find some slow parts, beside plugin loading and there specially a very slow GetLongPathName, but this should not lead to 30 sec loading time....

AndrewCot · « **Reply #21 on:** January 05, 2022, 12:10:12 am »

@BlueHazzard I have run both the devel31_64 and output31_64 binaries and they both start between 2 and 3.5 seconds depending on if the GNU GCC exe can be found as the code exits early if the gcc.exe cannot be found.

My analysis, which is based on adding timing output to the log and as such is crude indicates that the slow part appears to be the code in the AutoDetectInstallationDir() function when there are allot of compilers that are registered. I have refactored the AutoDetectInstallationDir() code as part of ticket 1117 as this was needed in order to determine if the compiler was not found or invalid and the code was convoluted and hard to follow (aka maintain), but ticket 1117 is queued up and there are other tickets I want to get resolved before it. The timing output to the log is included in my latest unofficial installer release.

I have tested using Miguel's config and it does not cause the load to slow down. I can only assume, which could be wrong, is that the directories being searched in the startup on a few machines cause the slowdown due to something specific on those machines. This is why I asked last month for Cappedcrusader12 to supply the compilers and directories so I could try and replicate the issue be changing my setup to hopefully match.

Miguel Gimenez · « **Reply #22 on:** January 18, 2022, 10:07:13 am »

I have experienced the slowdown (also 30 seconds) when mingw32-gcc.exe is in the system path.

AndrewCot · « **Reply #23 on:** January 18, 2022, 11:09:20 am »

Can you post your path?

Miguel Gimenez · « **Reply #24 on:** January 18, 2022, 11:12:33 am »

We have discussed this already, please see r12661 that includes your proposed changes to options_gcc.xml

Cappedcrusader12 · « **Reply #25 on:** January 27, 2022, 01:23:53 pm »

Sorry for my long hiatus, but i was on vacation as well and have been preparing for exams.

Quote from: AndrewCot on December 31, 2021, 04:27:24 am

I tried the config file and found that the Cygwin compiler was always shown in the Compilers auto-detection that pops up on start-up as Invalid due to the config not having a <compiler><sets><cygwin> [MASTER_PATH] entry. The C::B I was testing against was SVN r12612 code with the addition of timing output to the log to measure the approximate C::B startup time and the compiler XML files from ticket 374 as I am trying to track down a C::B slow startup issue Miguel seen. Miguel can I get a copy of your config?

After adding in the <compiler><sets><cygwin> [MASTER_PATH] entry I did not see any major slow down in the C::B startup (the XML file changes add an extra 1 second).

Cappedcrusader12 can I get the list of GCC and other compiler's you have installed with their root or bin directory along with what version of the compiler it it. For example:
MSYS2 Mingw64 - C:\msys64\mingw64

I have the following compiler's installed, but I prefix them with "test." when I am not using or testing them:
MSYS2 Mingw64 - C:\msys64
TDM 64 - C:\TDM-GCC-64
TDM 32 C:\TDM-GCC-32
Mingw64 - C:\mingw64
Mingw32 - C:\mingw32
Mingw - C:\MinGW
Mingw64 Guyutongxue C:\mingw64_gtx
Mingw64 WinLib C:\mingw64_winlib
Cygwin - C:\cygwin64

My compilers are:
TDM 64 - C:\TDM-GCC-64 ver. 10.3.0-2
TDM 32 - C:\TDM-GCC-32
They are both installed from the web installer.
@BlueHazzard i think i'm a bit above average when it comes to computers, I do not know what do you mean by compiling codeblocks. Can you elaborate?

Miguel Gimenez · « **Reply #26 on:** January 27, 2022, 02:00:50 pm »

Can you check the last nightly?. It has a change (now reverted) in compiler detection.

Cappedcrusader12 · « **Reply #27 on:** January 27, 2022, 05:38:57 pm »

I installed it now and it takes 40 seconds to open.

Cappedcrusader12 · « **Reply #28 on:** March 19, 2022, 12:59:42 pm »

Ok, so after reinstalling the 20.03 multiple times and repeteadly deleting the local files, the loading time fixed momentarily, but after restarting the PC the problem returned.

Cappedcrusader12 · « **Reply #29 on:** April 15, 2022, 07:20:02 am »

Ok, after reinstalling windows it now opens quick.

BlueHazzard · « **Reply #30 on:** April 15, 2022, 04:39:05 pm »

Good to hear.
Still would be interesting what took so long...

News:

Author Topic: Codeblocks long startup time (Read 14501 times)