I'm testing Nimony's incremental compilation by importing all std modules.
import std/encodings
import std/os
import std/math
import std/syncio
import std/appdirs
import std/assertions
import std/cmdline
import std/cpuinfo
import std/dirs
import std/encodings
import std/envvars
import std/fenv
import std/formatfloat
import std/hashes
import std/intsets
import std/locks
import std/math
import std/memfiles
import std/monotimes
import std/nifply
import std/os
import std/oserrors
import std/parseopt
import std/parseutils
import std/pathnorm
import std/paths
import std/rawthreads
import std/rlocks
import std/sets
import std/setutils
import std/strutils
import std/syncio
import std/system
import std/tables
import std/unicode
import std/widestrs
import std/wordwrap
import std/writenif
echo "ok"
echo "ok"
echo "ok"The compilation takes 1.9 sec, every time I add one more line of echo "ok", it takes 1.9sec.
I noticed they are compiled into .o files in the "nimcache" folder, seems like all of them are being linked into the final executable every time, which is causing this 1.9-sec delay. And it's slower when more modules are imported.
For debugging mode, is it possible to use .so instead of .o? I mean to completely avoid the final linking, only re-compile the modified module, which is likely faster.
The compilation takes 1.9 sec, every time I add one more line of echo "ok", it takes 1.9sec.
Well that's some lovely bug we need to fix, not something to hack around via DLLs.
Most of them are empty:
1.8 KB envto7w6l1.o
1.9 KB syn1lfpjv.o
2.7 KB teszpno6r1.o
342 KB static.o
6.6 KB sysvq0asl.o
952 B apppjmkv4.o
952 B assy765wm.o
... 41 empty .o41 of those .so are empty, linking against them adds ~1.5 seconds, after removing them it drops to ~500 ms.
Well that's some lovely bug we need to fix, not something to hack around via DLLs. We do dead-code-elimination though so these .o files should be empty? Please report it on Nimony's bug tracker.
Is this a bug? AI says it's normal for the linker to spend a second or two even when the only inputs are a few dozen empty object files.
previously:
# first build, commit 9c35879988e48eb7b96b1a38e9a7585fc00c81cc
Real time : 6 s 167 ms
User time : 4.9905 s
System time : 1.1428 s
Max RSS : 73.7 MB
# add echo, rebuild
Real time : 436.8 ms
User time : 0.2520 s
System time : 0.1825 s
Max RSS : 30.2 MB
# first build, commit 23135312f2389fd0d0380ad8f23a9f6666ff8857
Real time : 6 s 347 ms
User time : 5.0854 s
System time : 1.2282 s
Max RSS : 73.8 MB
# add echo, rebuild
Real time : 45.5 ms
User time : 0.0267 s
System time : 0.0174 s
Time : 44.2 ms (44.174 ms/per)oh, then it's
executed commands:
nimsem 2.194s (44 invocations)
executed commands:
hexer 1.282s (45 invocations)
cc 0.632s (46 invocations)
nifc 0.101s (45 invocations)
dce 0.096s (1 invocations)
link 0.023s (1 invocations)
executed commands:
nimsem 0.015s (1 invocations)
executed commands:
dce 0.094s (1 invocations)
hexer 0.006s (1 invocations)