Should be titled "without using malloc" or something. It's pretty much impossible to do anything with user input strings unless you have some sort of memory management. Maybe you have one giant buffer that you use for strings in a particular session, but that still involves memory management because even if you allocate the buffer at startup, using one buffer for multiple strings is just a type specific arena allocator.
As someone who works on low level database code, this approach is going to be EXTREMELY wasteful. Instead, it's much better to instead have a more sophisticated understanding of memory use by subsystems and have some concept of required memory and caches. Each system allocates the minimum memory it needs at startup and then treats the rest of memory as caches which can be emptied as necessary to preserve fairness among all the various subsystems.
> Should be titled "without using malloc" or something. It's pretty much impossible to do anything with user input strings unless you have some sort of memory management
Title says "without dynamic memory allocation" == what means without malloc in this context, so static memory allocation ... where you do your own kind of memory management in fixed size arrays or more sophisticated if you want. It didn't say without memory management?
(And article explains also why no strings or other unknown/arbitrary length stuff..)
> using one buffer for multiple strings is just a type specific arena allocator.
Sure, but there's a lot of advantages of entirely controlling memory allocation in-process.
> this approach is going to be EXTREMELY wasteful.
Could you elaborate why? Sure, you have to do a bit more juggling in-process, but I would imagine this would be potentially more efficient than having conventional mallocs.
In the environment it is designed to operate in, there is usually a fixed memory limit per process, so you might as well grab all that up front.
> I would imagine this would be potentially more efficient than having conventional mallocs.
Yes, in our experience, static allocation means we use sometimes 10x less memory. For example, TigerBeetle's storage engine can theoretically address up to 100 TiB with less than 1 GiB of RAM for the LSM in-memory manifest, which is efficient.
Because we think about memory so much upfront, in the design phase, we tend not to waste it.
I think it should be noted that TigerBeetle is an extremely specialized database. It's not a general-purpose DB for storing arbitrary data, all it stores is numeric financial account information.
As someone who works on low level database code, this approach is going to be EXTREMELY wasteful. Instead, it's much better to instead have a more sophisticated understanding of memory use by subsystems and have some concept of required memory and caches. Each system allocates the minimum memory it needs at startup and then treats the rest of memory as caches which can be emptied as necessary to preserve fairness among all the various subsystems.