3 ms·
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
by estebarb 2y 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 2y agoTigerbeetle 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 2y agoTechnically, 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 2y 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...