3 ms·

> that C programs spend a lot of time allocating and releasing memory ...then this code didn't get the point of manual memory management, which is to minimize

> that C programs spend a lot of time allocating and releasing memory ...then this code didn't get the point of manual memory management, which is to minimize allocations and move them out of the hot path. Unfortunately a lot of C and C++ code is still stuck in a 1990's OOP model where each individual object is explicitly constructed and destroyed, and each construction and destruction is linked to an alloc/free call. If you do this (or reach for reference counting, which isn't much better), a GC is indeed the better choice.

estebarb 3y ago
Moving out the allocations/releases out the hot path seems too much like a GC. Also, not all programs can be easily optimized moving the allocations: databases are an example, usually you don't know how much rows are you going to touch until you process the query.
- flohofwoe 3y ago
  Tigerbeetle is famously a database that doesn't do dynamic memory allocation at all (after startup): https://tigerbeetle.com/blog/a-database-without-dynamic-memory https://tigerbeetle.com/blog/a-database-without-dynamic-memo...
- Nevermark 3y ago
  Technically, GC can be part of manual memory management. The "manual" doesn't mean any algorithm is ruled out - it just means the developer mindfully chooses the right algorithm for the right situation. As apposed to the language, compiler or system always making those decisions.
- pjc50 3y ago
  > Moving out the allocations/releases out the hot path seems too much like a GC Absolutely not. It just requires a certain amount of planning and puts work on the callers to ensure that they prepare a suitable allocation somewhere, which may be on the stack or inside some structure or array that already exists. The limit case is the common embedded style of statically allocating everything. Often combined with a ban on recursion and (manually or automatically enforced) limits on stack size. If you don't have a lot of bytes you can plan your usage of each of them individually. MISRA rule 20.4 just plainly states "Dynamic heap memory allocation shall not be used." The very opposite of GC. https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Reference.pdf https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Referenc...

estebarb 3y ago

Moving out the allocations/releases out the hot path seems too much like a GC. Also, not all programs can be easily optimized moving the allocations: databases are an example, usually you don't know how much rows are you going to touch until you process the query.

flohofwoe 3y ago
Tigerbeetle is famously a database that doesn't do dynamic memory allocation at all (after startup): https://tigerbeetle.com/blog/a-database-without-dynamic-memory https://tigerbeetle.com/blog/a-database-without-dynamic-memo...
Nevermark 3y ago
Technically, GC can be part of manual memory management. The "manual" doesn't mean any algorithm is ruled out - it just means the developer mindfully chooses the right algorithm for the right situation. As apposed to the language, compiler or system always making those decisions.
pjc50 3y ago
> Moving out the allocations/releases out the hot path seems too much like a GC Absolutely not. It just requires a certain amount of planning and puts work on the callers to ensure that they prepare a suitable allocation somewhere, which may be on the stack or inside some structure or array that already exists. The limit case is the common embedded style of statically allocating everything. Often combined with a ban on recursion and (manually or automatically enforced) limits on stack size. If you don't have a lot of bytes you can plan your usage of each of them individually. MISRA rule 20.4 just plainly states "Dynamic heap memory allocation shall not be used." The very opposite of GC. https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Reference.pdf https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Referenc...