Compile Time

[Darmakwolf]

Now I understand this is something I likely can't change, especially on a large project - but is there anything that can slice a few seconds off of compile time? My project, to be fair, is gargantuan, and takes GLB about 25 seconds to compile. 

[Darmakwolf]

the only real influence you have on this is to partition your code into multiple source files - this will allow GLB to evaluate which of the files did not get changed since the last compile sequence.

Oh! Why didn't I think of that! Thanks!

[Marmor]

use a ramdisk

[Darmakwolf]

Well, that didn't go as expected. I seemingly can't just cut-paste a function into a separate source file. It "works" and compiles, but stuff gets ... wonky.... I mean some stuff doesn't show up, text disappears in some places, etc. Should I be doing something different? I used file->source code file-> new, added it to the project...

[kanonet]

Get a faster CPU.
BTW does someone know if GLB uses multiple threads for faster compile on 2+ cores? If not, how can we force this?

@Darmakwolf: Maybe close the project, open it again and see if things are ok now?

[Darmakwolf]

Aha - it was a fluke of some sort then. It's chopped compile time down by 10 seconds just moving functions to individual source files

[spacefractal]

but even its change one line of code, often its just recopile the whole thing from beginning. when that happens its take around 90 secs here for a around 13300 commands big source codes (Greedy Mouse). For some reason v11.171 is still faster and better to detect skips.

[kanonet]

Yes older versions are faster cause Gernot added some string packing magic later - it makes smaller (and maybe faster) exe files, but takes more compile time. afair-

[Moru]

Every time you switch from debug to normal there will be a complete recompile of the whole project. This is handy for those few times when the compile just won't recognize your changes in a file and uses the cached file.

Also, as Marmor suggested. If you have the RAM for it, use a ramdisk both for the cache and your project. I'm not sure how to get the whole of GLBasic into the ramdisk but if that is possible you will see great speedup. Most of the time it's not the CPU that is so slow, it's the harddrive :-) If you already have an SSD disk, you might not see so great speedup but there should be some difference still.

[mentalthink]

Yes I use RamDIsk and put GLBasic into the memory, I have 8GB of memory but really I only use 3Gb in Parallels, and I can put into the Ram... Really it's more faster but don't think it's like a thunder of quick...
I ear now it's time to use SSD drives, them are cheaper and seems the computer turns amazing faster.

[Kitty Hello]

I try to spawn separate threads for compiling. Should work. Only linking will be slow then. Another option would be to switch to clang instead of gcc.

Sent from my GT-N7100 using Tapatalk

[Schranz0r]

I think the real slowdown is :

if you only need the graphics and keyboard, you link all the other stuff like network, controller, sound...
bigger filesize = longer compiletime?

[mentalthink]

I read something in the Compiler -j4 4 it's the number of cores, but for me doesn't works... speak too about makefile -j , seems Gcc compiler can be paralelling computation, but I read sometime ago the Gcc help and don't say nothing about it...

But don't have too much sense if Gcc it's an actual compiler can't do this kind of process, if another compilers do it...

[Wampus]

After testing I found using a ramdisk didn't speed things up at all for my setup. However, I'm not sure whether that was because of memory caching cleverness in Windows 7 or something similar. Getting a faster processor did help (as it surely should).

[MrTAToad]

More memory might help too...