nim-chronos
nim-chronos copied to clipboard
status-im
macro code size explosion
the chronos async loop should be a fairly simple matter: it's a loop that runs callbacks - yet when compiling a simple app like nim-beacon-chain there is 1.4MB of code generated for it - something is wrong.
1,4M @m..@svendor@snim-chronos@[email protected]
Everything depends on compilation options:
Linux
nim c testtime.nim
-rw-r--r-- 1 cheatfate cheatfate 176409 Jan 30 09:01 @m..@[email protected]
-rw-r--r-- 1 cheatfate cheatfate 94800 Jan 30 09:01 @m..@[email protected]
nim c -d:release testtime.nim
-rw-r--r-- 1 cheatfate cheatfate 137262 Jan 30 09:10 @m..@[email protected]
-rw-r--r-- 1 cheatfate cheatfate 75984 Jan 30 09:10 @m..@[email protected]
Windows
nim c testtime.nim
01/30/2020 03:59 PM 174,210 @m..@[email protected]
01/30/2020 03:59 PM 78,856 @m..@[email protected]
nim c -d:release testtime.nim
01/30/2020 03:59 PM 141,748 @m..@[email protected]
01/30/2020 03:59 PM 62,881 @m..@[email protected]
Also asyncloop.nim of course includes asyncmacro2.nim but it do not have any {.async.} procedures.
In @m..@svendor@snim-chronos@[email protected] i see a lot of
#line 134 "I:\\Projects\\nim-beacon-chain\\vendor\\nim-chronos\\chronos\\asyncfutures2.nim"
nimln_(134, "I:\\Projects\\nim-beacon-chain\\vendor\\nim-chronos\\chronos\\asyncfutures2.nim");
This lines are present for every possible line of code.
The presence of nimln_ in code means that we are compiling asyncloop.nim in debug mode which is also adds size and additional code checks.
with --linedir:off --stacktrace:off --linetrace:off:
752 ./@m..@svendor@snim-chronos@[email protected]
[arnetheduck@tempus beacon_node]$ grep NIMCALL ./@m..@svendor@snim-chronos@[email protected] | wc
522 3676 82590
the macro transformations somewhere generate calls to generic functions that get repeated over and over..
long story short, asyncloop grows because of generic proc's that get instantiated by the async macro, so every time someone uses async/await in some other module, asyncloop grows..