Compilierungs-Geschwindigkeit Vergleiche

[spacefractal]

just to been noticed, that increble skips is quite very bad... and seen its not working with strings at all. Even you just change one char in a string, its all over again, and again and again.´

In not understand why eventuelt h file can not been updated alone here, without require recompile every time. This is something the precompiler needs more work on.

That why glbasic ended for me for big projects. That is simply no more fun.

But im do have a smaller project throught (Spot Race).

[S.O.P.M.]

Genau das ist mir auch aufgefallen! Bei Änderung von Strings wird immer alles komplett neu compiliert. Hat das technische Ursachen und damit gute Gründe oder ginge das auch anders?

[Kitty Hello]

Good find. I'll try to improve that.

Gesendet von meinem GT-N7100 mit Tapatalk

[S.O.P.M.]

Gernot, that would be totally awesome and I'd reward you with a donation for that! My project becomes larger and larger and it has a huge meaning for me to successfully finish it. Also please consider what I've suggested for compiling improvement.

[spacefractal]

im thinks the main issue is in that way strings works is due that way the c++ compiler create gpc_temp_class.h. Im dont like that way its does, which seen compiles all strings to randoms ID for any string used. So soon there is any change, that mean the ID might have changed, and cause the app require a recompile.

im do wonder why its want all thoses const CGStr without using hash values for the string used.... and also why its need to collect all strings that way.

So im thinks the main issue with the incribleskips not working is all due ineffective way glbasic uses strings.

[Kitty Hello]

The string reuse table is to improve the execution speed. It improved DDGui speed a lot. But I find a way for faster builds.

Gesendet von meinem GT-N7100 mit Tapatalk

[spacefractal]

Property a options to disable the string reuse table could improve the compile speed very much, but in  excharge might cause a slower execution speed. But when testing things im would property not notice that. Not on Windows/Desktops.

Also its dosent skips correctly when a id is changed on the table. You should have used a form for hash values to make sure id dosent changes.

Im thinks that is the main reason its recompile from beginnings quite often.

[spacefractal]

Sorry to repost, a another idea me thinkings, the string table could been done only when not compiled as debug version. But im dont thinks most users would mind a slower app when debugging thing anyway.... Also slow compile time when doing a release build, but fast compile time without that string table in the debug build. That could do the job nice too.

[kanonet]

Debug builds are slower then release builds already, so even if you speed it up a bit, I dont think this would make that many people much more happy.

Something partially different:
When compiling for Android, I see no reason to always compile release and debug apk, one of them(depending on the selection) would be fine, like its the case on any other platform too.

[spacefractal]

Its very different to wait 30 secs (when IncrediBuild skips happens) or 90 secs (when no IncrediBuild skips happens), if the main issue is due that way glbasic sorting strings in the table.... And yes debug builds is slower, so its no real means we needs to sorting strings that way, but im dong mind doing that in the release build of course.

On android with Android Extras, im did perfer debug version over than release version. This is due that way key signing works, so its much easier to do the debug version first for testing. Im cannot seperate the builds to each compiling, due that way glbasic calling the bat, so there is nothing im can due. Im whish there was two of them (one for debug and one for release), then its would not been a problem then.