2 ms·
Is it really though? 2mb is practically nothing on modern machines. And full-fat debug should have as much info as it can, why optimize it unless you're spittin
by spicybright 5y ago
Is it really though? 2mb is practically nothing on modern machines. And full-fat debug should have as much info as it can, why optimize it unless you're spitting out 400+mb binaries or something crazy.
It's like, yes, if you turn off the A/C in your muscle car, you'll technically get a few extra horse power.
But past some philosophical ideal of squeezing out every bit of horse power you can, it has a negligible effect on the operation of the car.
Now if you're working on a weed wacker engine or something, yeah that would matter. But you wouldn't pick a giant beefy engine and expect it to work as well as a tiny lightweight one.
- titzer 5y ago> 2mb is practically nothing on modern machines. There are plenty of embedded systems that have <= 1mb of memory. E.g. a popular one is Teensy (https://www.pjrc.com/store/teensy40.html https://www.pjrc.com/store/teensy40.html).
- AnIdiotOnTheNet 5y ago> Is it really though? 2mb is practically nothing on modern machines. In general, I agree actually. I think hemming and hawing over duplicated shared libraries in particular makes no sense for most modern systems. Still, 2MB is a pretty damn big overhead to put on every binary the way Go does. Not that it isn't a considered trade off or anything, I'm just saying. > And full-fat debug should have as much info as it can, why optimize it unless you're spitting out 400+mb binaries or something crazy. That's my point: there's no optimization in the full-fat debug and it does contain everything it can and it's still a little more than half the size of a completely empty Go binary. 2MB is huge. For the ReleaseFast version all I did was tell the compiler to optimize for speed and otherwise put no effort into making anything size efficient.
- spicybright 5y agoI'm still not really getting why "huge" matters though, unless you're doing very small embedded work. Which I'd argue Go isn't a great choice in the same way that running full linux on a limited microcontroller is not a good choice. Every systems language shouldn't have to over complicate it's run time to squeeze kilobytes out if 99% of use cases are running on modern personal computers. (C or TinyGo, or a variety of languages are better suited for embedded) Like, yeah, 5 cents is huge compared to 1 cent, but we're dealing in hundred dollar bills here.