11–15 of 15 posts
[0] https://blog.mozilla.org/nnethercote/2014/11/04/please-grow-...
In regards to growing array one-by-one, obviously be very careful with that. In C, issues to look out for are malloc overhead and memory alignment issues if you are not realloc'ing in even sizes. Also see Mozilla's recent post on this issue. [0] [0] https://blog.mozilla.org/nnethercote/2014/11/04/please-grow-...
I'm all for these types of optimizations, so long as they don't come with the price of readability. The more complex an optimization is, the more likely it'll cost more in the long run (developer time) than save (hardware resources). Hardware/Memory/CPU's are still much cheaper than developer time.
If you're writing software that others will be running, the calculation's a bit more complicated. You've got to consider your customers, and how much a performance change impacts their purchasing decision, and use that to estimate your revenue impact, and then compare that to the cost of developer time. And what comes out the other end of that is that developer time is often much cheaper than dissatisfied customers.
The case is similar on the Web, where tiny minuscule barely noticeable changes in application responsiveness can have a huge impact on conversion rate. Or worse yet, make the difference between your servers falling over or ticking along smoothly when that oh-so-important Cyber Monday traffic surge comes along.
In regards to growing array one-by-one, obviously be very careful with that. In C, issues to look out for are malloc overhead and memory alignment issues if you are not realloc'ing in even sizes. Also see Mozilla's recent post on this issue. [0] [0] https://blog.mozilla.org/nnethercote/2014/11/04/please-grow-...
Also you can 'foam' the heap if you continue to grow lots of allocations. Old freed fragments are never big enough to satisfy a new allocation, and your heap memory grows without bound.
Earlier quoted context omitted.
Also you can 'foam' the heap if you continue to grow lots of allocations. Old freed fragments are never big enough to satisfy a new allocation, and your heap memory grows without bound.
Interesting, I've never heard of this. Do you have any links to resources? I tried Googling, but to no avail. "c heap" looks like cheap, and "memory" and "foam" are all about mattressess...