7 ms·
there are just three things i wish programmers knew about memory... none of them are especially low-level or require depth of understanding. never dynamically
by jheriko 11y ago
there are just three things i wish programmers knew about memory... none of them are especially low-level or require depth of understanding.
never dynamically allocate it unless forced.
really. never allocate at run-time it unless you are absolutely forced by your algorithm.
if you absolutely really must allocate memory on the fly, have a budget so you can do one big up-front allocation and carefully reuse it. even better, don't allocate it to start with.
- progmal1 11y agoI feel like you are projecting your domain specific experience on a larger more general audience than is appropriate.
- jheriko 11y agoyou are probably right
- rootlocus 11y agoI'll remember that the next time I'm using python.
- azinman2 11y agoOr Java or go or ruby or Scala or php or....
- vvanders 11y agoStill very much relevant in Java if you don't want your GC to churn like mad. Heck even some of the cache aware algorithms can be taken advantage of with some smart use of ByteBuffers to get a 10-50x improvement in performance.
- azinman2 11y agoFew applications need this... mostly in the financial space. The GC is quite good at quick temp objects these days.
- jheriko 11y agoi'm not sure using a dynamic late scripting language is an excuse for pretending memory is infinite. :) but yes... i do have frustration from "highly skilled native programmers" who seem to think that memory is a boundless resource and then complain that something like 32GB is a constrained memory environment when it is the exact opposite.
- yongjik 11y agoThat will basically prohibit using most of C++ STL, for example. Premature optimization is the root of...
- jheriko 11y agoi'm not a fan of that religious statement. its assuming it is premature. STL is not too bad either. you can make it work with budgets too... implementing a custom allocator is a pain, but there are lots of ways to not write code that imagines that memory is an infinite resource...
- aidenn0 11y agoYou do know that function stack frames are dynamically allocated (just not from the heap in most C and C++ implementations).
- Namrog84 11y agoMaybe he is coming from the fact that lots of things still leak memory this day and age. And you tend to not leak memory when you avoid dynamic allocation? Though you can still build up crud depending upon the system.
- jheriko 11y agoin a sense yes, but its not a realistic way to use the term. what happens is that the stack is once dynamically allocated up-front when the thread is created and an index into that blob of memory is incremented and decremented as appropriate (stack pointer). you can call that allocation, and it would be accurate but its not what i meant at all. it also avoids growing your memory consumption and doesn't impact memory budgets no matter how much stack you try and use (you will overflow it instead... and will need to allocate a bigger budget upfront for the stack with a compiler flag)
- rikkus 11y agoIt would help to give reasons why rather than simply commandments. I'll give one: Performance takes a hit with dynamic allocation. Deallocation also has to occur and if you use GC you may experience pauses as this happens. Your GC may vary. The performance inpact of dynamic allocation may of course be completely acceptable when traded against productivity gains.
- jheriko 11y agotrue. i wasn't just thinking about performance but also budgetting. using memory as an endless resource without thinking seems to be standard practice rather than something that is considered "sloppy". there is also the practice involved. run-time allocation is a bit of a golden sledgehammer and a double edged sword... sure you can write code more quickly, but you are also being enabled to write worse code (i.e. leaks). i don't think we should take the power away, but respect it more...