- avoid struct types which contain both integer and pointer fields
- avoid struct types containing arrays such as [100]byte (replace it with *[100]byte or with []byte)
- avoid data structures which form densely interconnected graphs at run-time
- avoid deep call chains at run-time
- replace pointer identity with value equivalence (this can lead to a more explicit memory management in your program)
- if a data structure contains both long-lived and short-lived fields, move the short-lived fields into a separate data structure or into local variables of a function
- avoid integer values which may alias at run-time to an address; make sure most integer values are fairly low (such as: below 10000)
- if you are using caches to speed up your program, apply the rules mentioned here to redesign the cache. It may also help to use strings instead of structs as map keys.
- lower the overall memory consumption of your program
- carefully speed up your program (this may lead to a lower memory consumption in certain situations)
- call runtime.GC() (at the right moment)
Name:
Anonymous2012-04-15 15:43
>>13
All those points are pretty funny, but they would be better if you added some emphasis in the right places, here I'll show you.
>>19
You can't call it a toy language just because it's still somewhat domain specific.
Name:
Anonymous2012-04-16 15:37
Go's GC was never intended to be final, just a stopgap until some awesome GC from IBM could be used. Unfortunately IBM still hasn't completed it, so for now we're stuck with the crappy one. The GC's behavior is an implementation detail, not part of the language spec; it can (and undoubtedly will) be changed later. Further, the authors were clear that "1.0" didn't mean "nothing left to do," but just that 1.0 code should continue to be backwards-compatible with subsequent versions (something that the earlier releases did not guarantee.)
Name:
Anonymous2012-04-16 16:11
>>22
GC is great. Golang is shit. Nice doubles. You're shit.