4 ms·
Something that could help a lot with performance would be functions to handle memory for many small blocks at once. Like a malloc extension function that al
by benibela 7y ago
Something that could help a lot with performance would be functions to handle memory for many small blocks at once.
Like a malloc extension function that allocates many small blocks at once. Rather than returning one block of size n, it would return k blocks of size n.
Of course the user could do something similar by allocating one big block of size k · n ordinarly. But then the user needs to keep track which small blocks belong to which big block, and it might too big, when some small blocks are not needed anymore. Say, the function needs k small blocks temporarily for processing, but only returns k/10 small blocks. Then 90% of the memory would be wasted.
But if you could allocate k small blocks at once, the allocator could allocate one big array of k·(n + sizeof metadata). Then each of the small blocks could be freed like a normally allocated block of size k, but they have all the advantages of quick allocation and cache locality like a big array.
Or, alternatively, there could be a partial free that does not free the entire malloced block, but only a part of it. Then you could allocate a block of size k·n, and when you do not need it anymore, free the 90% of the block that you do not need, but keep the 10% that you need.
- scott_s 7y agoRegion-based allocation is similar to this: https://en.wikipedia.org/wiki/Region-based_memory_management https://en.wikipedia.org/wiki/Region-based_memory_management
- munchbunny 7y agoObject pools are a pretty common pattern for that kind of usage. Is this any different, or are you just asking to push the "allocation" into the memory allocator instead?
- benibela 7y agoThe difference would be that each object can be freed individually when it is no longer needed. Especially when the code that creates the objects and the code that uses/discards the objects are in two different projects. Like a library that can load a JSON file as some kind of tree structure. Then someone uses the library, loads a file of a million objects, but then only needs a single object. All the other objects should be freed, but if they are in a pool, they cannot. The library does not know which object the user wants, and an user of the library should not need to know how the library allocates the objects
- munchbunny 7y agoI needed some time to think about your point. :) I'm not sure I understand the distinction. Why couldn't the parser maintaining that pool? If the two different projects (which I assume translates into two different object files or DLL's) belong in the same process, it's pretty straightforward for the parser to keep a singleton pool somewhere. If the two projects are in different processes, then it's probably better in terms of security to disallow sharing of that memory - and virtual memory spaces should abstract the space efficiency issues well enough for those purposes.
- benibela 7y agoThe problem is that the pool becomes too big and wastes memory It is fine when the user keeps opening files and the parser can reuse the objects. But eventually, the user has opened all the files he needs. Then the process will never open another file again, and none of the objects can be reused. But they also cannot be freed, when some objects are still used, e.g. when the user did not close all files.