4 ms·
Another way of seeing it is that "40% of the code became imaginary", in the sense that you have to figure out what the macro is expanding to. I'm not against g
by haolez 3y ago
Another way of seeing it is that "40% of the code became imaginary", in the sense that you have to figure out what the macro is expanding to.
I'm not against generics. I was just wondering myself in a boring afternoon :)
- Ar-Curunir 3y agoHm but the same argument can be made for anything the compiler does, no? Like I have no idea of how the compiler handles the `Interface`-based approach either.
- AaronFriel 3y agoThe article is about performance or CPU time, not code size. Per the first paragraph, "In this blog post I’m going to show how, using the generics, we got a 40% performance gain in an already well optimized package, the Google B-Tree implementation."
- hedora 3y agoI’m reasonably sure that running it through godbolt or using a coverage tool would show the (reachable) part of the program is smaller.
- nkozyra 3y agoIn this case I don't think there's really any mystery or hidden code, though. Functions that operate on collections (or set-like structures) are what generics are most commonly used for, so there shouldn't be much surprise.
- deleted 3y ago[deleted]
- eru 3y ago> Another way of seeing it is that "40% of the code became imaginary", in the sense that you have to figure out what the macro is expanding to. The compiler does lots of internal 'expansion' steps in all kinds of different internal formats to spit out machine code at the end. We typically wonder what all those intermediate steps are. Why should we suddenly care, just because one of those internal formats can be interpreted as being compatible with an earlier version of the Go language? (I don't say, that the internal format _is_ the Go language, because I doubt their internal representation looks like the bytes you have in your .go file.)