This is pretty much going me to very insane and frustation.
Today im thinks im have waited about a hour just to wait the glbasic to compile the application total, its so slow im might choice to skips glbasic for my next project (those large projects). something that is much faster to compile.
The reason is that incredible skip that is included glbasic barely works for me at all, and have not do its job done since v11 (v10 did works better). That tool need to been much better than its all, so im cant call it increbible skips at all, when its never do that.
Even when im just change ONE char in a string, its dosent invoke the incredible skips parse at all, which is so annoying.
why does its not work? Here BlitzMax works about 1000 times better.
A fix to this slowless of glbasic could something like this:
- A toogle icon to force glbasic to uses increble skips on other than the source code file you are in, so only one source code is compiled, which would speed up very much. This should just been a feature icon. That due a change might produce FATAL ERROR, due glbasic cant checks other files.
It is not the first time people complain about ages in compiling time.
I wonder what is it about, I have no experience whatsoever,
Maybe the function > type made it necessary to full code compile in some occasions? I don´t know.
Would be nice to know, what are your experiences with compiling?
I have:
Wordcount:4255 commands
Takes about 12 seconds to full compile, all in one listing.
What's speed like for all code or 90% in onegbas file?
Viking invaders is 9000 lines and compiles in 20 secs.
Maybe some thing is slowing your compile down?
speed for one gbas file is not a issues, typical about 15-25 secs = nothing problem at all. But rarely happens.
Speed for whole source code is about 85 secs with 13500 commands. Greedy Mouse is a quite bigger then Karma Miwa, but my third games is not half that big and will not do that. Its a little game.
Alternative im would like to see the steps glbasic does, etc checking for media, compile time and other thing its does, so its could compare step to step. But its do fell very long time for full compiling.
PS. Im dont mind compile time when compile for other platforms really at all.
Quote from: spacefractal on 2014-Apr-27
...
PS. Im dont mind compile time when compile for other platforms really at all.
Agreed, we are looking into compiling at PC, so to test things out as quick as possible.
Your 13k commands seems comparable to my time, do media count in it? I have a lot of useless media into the media folder, maybe it takes time into the compiling phase to make things out.
its seen not. when its skips, the lowest time was about 13.5s, typical about 20s.
So that way im want to see a feature to force glbasic to skips other source code.
but 85-90 secs is really long time for each compile.
Do you have functions/types kind of relationships? I noticed complains on time to compile started from when that got in.
Im not sure I IncrediBuild is completely working or is bugged. But even if its not bugged, you should remember, that it works on base of the generated C++ files, not the gbas! When you compile your project it is splitted in several files: every gbas becomes a cpp file, but there is also a global header that is used by every file. If you change something that will be in the header, not in the cpp, then all files that use this header (=your whole project) needs to get compiled again. Things that are in the headers are:
global variable definitions
type definitions (names and containing variables/members)
definitions of functions and functions of types (only the definition = names, return type, parameters, NOT the function code itself)
all string literals (yes since V11)
So if you keep this in mind you may have a better compile. All said above is from my experience and code analysis, so not 100% guaranteed, but maybe its a good start for you to find out yourself.
Quote from: kanonet on 2014-Apr-28
When you compile your project it is splitted in several files: every gbas becomes a cpp file, but there is also a global header that is used by every file. If you change something that will be in the header, not in the cpp, then all files that use this header (=your whole project) needs to get compiled again.
You're right, this is why the code must be structured perfectly.
Personally, I have restructured my code (8000 lines :S) because I had this problem.
But when small change not invoke skip, example change content on a string.... Even one simple change.
Something not happens with blitzmax.
Like I said: all strings are in a header, so you need to compile the whole project again.
Strings has a very easy solution:
Keep them all in external files that you read in on runtime, not compile time. This has a nice side-effect of making it very easy to support more languages. This is what the ini files are for anyway.
Usually people have the problem that code gets skipped even though it was changed. Often this is caused by using a USB-drive to work from. Don't work on USB-drives, they are not very safe.
To force a recompile of the whole project in these cases is made by toggling debug mode off and on again. Is this maybe something you do often?
Then it's should only update the header instead.... It's still stupid.
Please don't throw stones. You know the rest... :-)
https://xkcd.com/844/
blitzmax can skips correctly and is a quite insane fast compiler (even im have a around 1mb source code in it), while glbasic allways have been insanely slow.
I agree, however BlitMax is a bit different to GLB. For starters BMax is modular and only compiles those modules that it needs based on the code (and is even better if you use the code checking tool). GLBasic compiles everything in one package. GLBasic file sizes are larger for the same reason. GLB is also catering for multiple formats - BMax only compiles to two.
I asked Gernot years ago if he had plans to make GLB modular.
There's no reason to repeatedly compile/increbuild thousands of lines of code each time. To compile quickly, I have a temp.gbas file added to the project where the new code goes (and cut and pasted to the old file later) so that only that get "incredbuilt" and skips the large old unchanged code file/s.
Is your project stored in a DropBox folder? Just wondering if this is causing false recompiles.
One more option is compiling individual modules into separate library files (GBAL extension?).
This would work great for library files that aren't very specific to your game project.
They now should no longer recompile at anytime. (I have never tried this however, but was curious)
no, im not uses dropbox for any glbasic projects.
im would like to see a choice where its compile the header file alone, and the current source code- Of course there mightbeen issues other place, here we should just see FATAL ERROR. Then the whole thing needs recompile of course. Howover its doesnt need to been detected automatic, but more just manually.
Can you make the project (and code) available - and we'll see how fast it is...
no. None of my games is open source. The test was based on Genius Greedy Mouse project, which is the biggest game (440kb source code in 18 files). Im do sometimes do snippets. But its seen its compareable to the Erico game.
Howover its would been nice to see more indepth status what glbasic is doing.
One asked on a timer based code, which im still wait to see a new thread about it, so im can post it. Not sure who asked it.
Quote from: Ian Price on 2014-Apr-28
I agree, however BlitMax is a bit different to GLB. For starters BMax is modular and only compiles those modules that it needs based on the code (and is even better if you use the code checking tool). GLBasic compiles everything in one package. GLBasic file sizes are larger for the same reason.
It's false, GLB is based on GCC and GCC works with libraries, it don't compiles everything in one package ::)
The reason for the difference in size, is because BMax compiles directly in Assembler.
The only valid reason to explain the very long time of compilation on some computer (other than the size of the program or a possible virus on the computer) is the reason given by Kano:
Quote from: kanonet on 2014-Apr-28
When you compile your project it is splitted in several files: every gbas becomes a cpp file, but there is also a global header that is used by every file. If you change something that will be in the header, not in the cpp, then all files that use this header (=your whole project) needs to get compiled again.
Snoopy, you misunderstood what I meant by "one package" but I'm not going to bother explaining it after the last discussion we had over nothing at all.
Quote from: Ian Price on 2014-Apr-30
Snoopy, you misunderstood what I meant by "one package"...
Yes, yes.. I have understood very well , you speak even of modules with blitmax. It's you who don't know what you're talking and use terms which you do not master.
Quote from: Ian Price on 2014-Apr-30
...but I'm not going to bother explaining it after the last discussion we had over nothing at all.
If you hint to our discussion on 3D engine, It's not my fault if you confuse a "3d Graphic Engine" (the 3D display) with a "3D Engine" (3D graphic engine, 3D physic engine(collision,...), 3d logic engine (IA, ..), ...)
I noticed that you often say false things with great conviction.
But you are right, me too I prefer not to converse with a person who never recognizes his own errors. ;)
And I repeat the difference of size between BMax and GLB is because BMax compiles directly in Assembler, and not for a supposed reason of modules that BMax would have, but not GLB.
Really I don't see too slow when compile... I did something with Visual Studio and this waste a lot of more time than GLbasic.. and it's very expensive.. Ok Express don't.
Really 30 seconds for 5000 commands + or -, perhaps because I come from 3D and I have to wait 2 hours for a shit lovely :-* image ....
My app is quite bigger. So whatever said it's still slow for big projects and could been better here. But again most quick test is allways is on windows.
Did you try moving everything to a ramdisk? Are you using a USB-disc for the source?
just a normal harddrive (on D: Drive). Im do should uses ramdisk. Howover if its a compile issue, its more depend on the cpu, more than harddrive. But nice idea.
Im do not think the third project will been a issue, since its a loth lesser project than both my games. Im also looking to port few games from the past im created to Glbasic.
PS. Tried with RamDrive. This seen is not a slow hardrive issue (im even remember to move the TEMP folder to ramdrive of course), since the speed was around the same. So its more a CPU thing.
Time to fork for dozen of processors and a water heat sink to overclock it all? ;/
hihi, no, im wont do that.
Its seen karma miwa is around 45-50 secs for around 8500 commands (Karma Miwa), so its quite compareable. Also the g++ compiler is quite old. Any reason for that? Howover here im dont mind really.
PS. im dont thing glbasic is good for so big games as Greedy Mouse was, howover its still a cool language for lesser thing. My third game is not that big, not even compared for Karma Miwa. Im do have not worked on that recently yet (its in bonus section).
I would like to see a later version of GCC being used - unfortunately Gernot did try it a while ago, and the Linux results weren't... good...
The most obvious way around that, of course, would be to do seperate editors and compilers for each platform, but that would take far, far too long...
im do hope this got fixed, because im are more more tired this slowless with so long compile time, and that start from beginning so much without reasons and its not just strings. That also happens im im just change a value in a integer or even added a new call to a function, that exists.
That is more more begin frustration and annoying me so much as im might leave glbasic due for this slowless (for now), which have been much worse since v10, because im have wasted so much time only just waiting (hours), and sometimes you need to press F5 twice to get the app running.
This can been why im have not have focus on my next game (even compile time here is not a issue, due its a little project), which can been seen in the bonus section (a little simple finger race game). Im can simply not hold my frustration back, and then im simply got un focused in a while.
Im do have to say, glbasic do works quite well and cool with lesser projects with under around 5000 commands. Here its not a issue at all. But The IncrediBuild skips could have been much better really on Windows.
Im hope Gernot add a function to force it to skips in the EDITOR, so its only recompile headers and the current source code file.