Nim v2.0.0
gc: orc
opt: speed
app: lib
https://github.com/panno8M/godot-nim/tree/v4.1
nim c demo/src/demo.nim
Compilation takes a long time.
About 170 seconds with -f option and 120 seconds without.
As far as the output is concerned, Nim->C is taking a long time.
10,000 functions are declared as prototypes only, and the information specified in pragma is used to generate processing in macro.
https://github.com/panno8M/godot-nim/blob/v4.1/src/godot/classes/classDetail_native.nim
https://github.com/panno8M/godot-nim/blob/v4.1/src/godot/helper/engineClassDefiner.nim
Heavy use of generics, converters, and concepts. Each of these is expanded into the large number of functions listed above.
It is difficult to properly separate modules and organize dependencies due to the automatic generation of bindings, so all of the above functions are deployed in a single module.
Thanks for reading!
Nice to see bindings for Godot.
NimForUE had similar issues now it (re)compiles for a new project (~250k LoC) in about 3 seconds on a M1 Max and < 100ms when using NimScript (experimental) :P
First thing I would do is to measure Nim's compilation times (use --compileOnly):
For the generated code, the intimidate remediation is to use PCH in all your headers (this made NUE to go from 2M+ to 15s)
For the bindings itself stop using macros, what you should do is to repr those macros and use the resulting Nim instead. NUE has a separate process for this which is triggered also when the user adds new C++ code or installs a third party plugin.
Finally, if times arent good yet, exportc the bindings from above and import them back as a library so you skip the proc body sem
BTW I would use the C++ backend for doing the bindings and emulate/bind godot cpp.
For the bindings itself stop using macros
I like to say that macros should be used for syntax sugar only. I've seen cases in Rust and also Nim crypto folk that are trying to derive numbers in there and making their builds slow because its trying to compute prime numbers and the compiler stopped caching modules somewhen versions ago.
about 3 seconds on a M1 Max and < 100ms when using NimScript (experimental) :P
That's cool! x30 times faster.
A side question, I wondering how Nim compilation works. Is it like a) validating Nim types ~100ms and b) compiling C-code and producing binaries ~2900ms? So, if you don't need binaries, you can speed up like x30? (I never use binaries, I always run Nim programs as ruby/python nim r app.nim).
Thanks.
nim r app.nim makes a binary.
Yes, I know, I don't need the binary though, and if there's a faster way to compile without the binary I would like to use it.