3 ms·
^^ what he said. Definitely high on the list. I debated just making this code build the executable, but given that they end up a couple megs each, and that go
by NateDad 10y ago
^^ what he said. Definitely high on the list. I debated just making this code build the executable, but given that they end up a couple megs each, and that go run is quite fast (~120ms).. I figured the default of just writing the file would be fine.
- cyphar 10y agoI'm fairly sure that "go run" does build the executable, it just deletes it afterwards (or it generates the file in memory).
- NateDad 10y agoSorry. What I meant was that I considered generating the binary and leaving it around, but instead I generate just the code and rely on go run to create and then delete the binary.
- cyphar 10y agoMy point was that go run being "fast enough" doesn't really mean anything -- it's precisely the same speed as go build. :P
- NateDad 10y agoBy fast enough, I mean this: The tradeoff between go build and go run is that go build makes subsequent runs faster, but it creates a somewhat large binary that takes up disk space. So, when I say go run is fast enough, I mean that the speedup of using go build is not big enough to justify the extra disk space required to store those binaries, compared to the speed hit we get from using go run each time (IMO of course).
- artursapek 10y agoI see what you mean. However in a situation where you might be running the command many times (like in a script that goes through data or something) then it might make sense to precompile it. The compile time would add up fast if it was being run hundreds/thousands of times.
- NateDad 10y agoAnd this is why I'm intending to add a -c flag (and maybe a global config of some sort) to tell gorram to use a compiled version instead.