macro code size explosion about nim-chronos HOT 4 OPEN

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.

from nim-chronos.

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.

from nim-chronos.

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..

from nim-chronos.

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..

from nim-chronos.