He did mention "quick compile times" as a draw and macros can slow down compile times/that kind of performance, but sure run-time performance of compiled code should be unimpacted.
EDIT: FWIW, compile-times impact mostly just depends on what he wants to do. The macro evaluator not that slow a virtual machine. Simple substitution macros tend to run quite fast. But it's also easy (with loops!) to generate a large pile of Nim code that generates a ginormous pile of C code that the backend might have to chew on for quite a while.
Have written quite a lot of macros, unless you're doing something really crazy you should be fine. The one time I've really run into macros slowing down compilation a lot was when I wrote my protobuf library which parses a protoc file during compile-time and generates all the required types and procedures. And that was mostly because the parser I used was really poorly optimized.
Comments
Macros shouldn’t have any performance implications.
The whole point is that they happen at compile time.
He did mention "quick compile times" as a draw and macros can slow down compile times/that kind of performance, but sure run-time performance of compiled code should be unimpacted.
EDIT: FWIW, compile-times impact mostly just depends on what he wants to do. The macro evaluator not that slow a virtual machine. Simple substitution macros tend to run quite fast. But it's also easy (with loops!) to generate a large pile of Nim code that generates a ginormous pile of C code that the backend might have to chew on for quite a while.
100% about compile times. Sorry, wasn't clear about that.
Have written quite a lot of macros, unless you're doing something really crazy you should be fine. The one time I've really run into macros slowing down compilation a lot was when I wrote my protobuf library which parses a protoc file during compile-time and generates all the required types and procedures. And that was mostly because the parser I used was really poorly optimized.