NG Delayed compiling. Normal?
BlitzMax Forums/Brucey's Modules/NG Delayed compiling. Normal?
| ||
| On my system,(win7,64: NG_0.66.3.07) compiling takes a really long time. I just want to find out if it's normal or abnormal. Regardless of build option or architecture, when I hit the build button (verbose:on) the output will show 'Building <filename>' and nothing for about 20-30 seconds. After that time the ide will start to show the verbose output "C:/Dev/Lang/BlitzMaxNG/bin/bcc.exe" -g x86 -v -r -t gui -p win32 -o" .... This delay happens even if the source file has not been altered since the last compile. Ex: "Building <filename>" {wait 20 seconds} "Executing:<filename>.exe" Another thing I noticed is that If I watch taskmanager during this delay, I see what appears to be bcc.exe loading and unloading from memory repeatedly. Is this normal behavior? |
| ||
| Do you use Bruceys version of MaxIDE ? Why am I asking? BMK-NG allows for the "quick" param which skips checking if a (imported) module needs a recompilation. So if you do not use "framework" for your code, it imports every available "standard" module - which is not lightweight - and this leads to some hundred of file checks. if you see the bmk-command used, copy paste it - and inject "quick" - and check then, if it changes something. bye Ron |
| ||
| Ya, sorry for not making it clear, I'm using the ide contained in the lastest binary release on bmx-ng.com, but it's been present in all the binary releases. It occurs on everything, regardless of the content of sourcecode or compiling options. even: SuperStrict Framework brl.basic Print "Hello" Result: Building untitled1 -=[ ~20 SEC DELAY ]=- [ 98%] Processing:untitled1.bmx "C:/Dev/Lang/BlitzMaxNG/bin/bcc.exe" -g x86 -v -r -f brl.basic -t gui -p win32 -o "C:/Dev/Lang/BlitzMaxNG/tmp/.bmx/untitled1.bmx.gui.release.win32.s" "C:/Dev/Lang/BlitzMaxNG/tmp/untitled1.bmx" Parsing... Semanting... Generating interface... Generating header... Generating source... [ 99%] Compiling:untitled1.bmx.gui.release.win32.x86.c C:/Dev/Lang/BlitzMaxNG/MinGW32/bin/gcc.exe -I"C:/Dev/Lang/BlitzMaxNG/mod" -DNDEBUG -I"C:/Dev/Lang/BlitzMaxNG/mod/brl.mod/blitz.mod" -I"C:/Dev/Lang/BlitzMaxNG/mod/brl.mod/appstub.mod" -I"C:/Dev/Lang/BlitzMaxNG/mod/brl.mod/basic.mod" -w -DBMX_NG -m32 -ffast-math -fno-exceptions -c -O2 -s -o "C:/Dev/Lang/BlitzMaxNG/tmp/.bmx/untitled1.bmx.gui.release.win32.x86.o" "C:/Dev/Lang/BlitzMaxNG/tmp/.bmx/untitled1.bmx.gui.release.win32.x86.c" [100%] Linking:untitled1.exe "C:/Dev/Lang/BlitzMaxNG/MinGW32/bin/ld.exe" -s -stack 4194304 -subsystem windows -o "C:/Dev/Lang/BlitzMaxNG/tmp/untitled1.exe" -L"C:/Dev/Lang/BlitzMaxNG/MinGW32/lib/gcc/x86_64-w64-mingw32/5.1.0/32" -L"C:/Dev/Lang/BlitzMaxNG/MinGW32/x86_64-w64-mingw32/lib32" -mi386pe "C:/Dev/Lang/BlitzMaxNG/tmp/ld.tmp" Executing:untitled1.exe "C:/Dev/Lang/BlitzMaxNG/tmp/untitled1.exe" Hello After the delay, everything else happens very quickly. I don't recall ever seeing bmk referenced in the verbose output. |
| ||
So you did not try "quick" (do not mix that up with the other existing param "-q") ?$ time ./bmk makeapp -a -quick tests/hello.bmx [ 90%] Processing:hello.bmx [ 95%] Compiling:hello.bmx.console.debug.linux.x86.c [100%] Linking:hello real 0m0.269s user 0m0.175s sys 0m0.072s $ time ./bmk makeapp -a tests/hello.bmx [ 98%] Processing:hello.bmx [ 99%] Compiling:hello.bmx.console.debug.linux.x86.c [100%] Linking:hello real 0m0.329s user 0m0.252s sys 0m0.060s This might be even more / longer for you. Nonetheless 20seconds is a bit long. Maybe you have an AV tool active which slows down file accesses. edit: Building untitled1 -=[ ~20 SEC DELAY ]=- [ 98%] Means, it took 20sec to do the first 0-97% ... which is the module scan (I assume so). bye Ron |
| ||
| Just checked over here... Works as per-usual! Very peculiar! :/ Dabz |
| ||
| I tried with the -quick flag and that seems to eliminate the delay. I guess I need to patch and recompile the NG maxide. Is the ide built with vanilla bmax or with NG? |
| ||
| I'll add the option to MaxIDE for the next release. |
| ||
| Further going details about the delay: https://github.com/bmx-ng/bmk/issues/10 https://github.com/bmx-ng/bmk/issues/8 The second/last one also contains some potential ideas how to circumvent the lag (module-info-cache). bye Ron |
| ||
| The -quick option gets around the issue... |
| ||
| But "-quick" removes the convenience of an auto-rebuild-all-needed-modules functionality. Best would be the mix of both worlds. bye Ron |
   |