Date: Tue, 20 Sep 2022 20:37:53 +0200 From: Quentin Rameau <quinq@...th.space> To: musl@...ts.openwall.com Subject: Re: The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) Hi Alexander, > > Exactly. This can be done entirely at the application layer just by > > keeping track of the size you allocated. In the above example, the > > number 256 kB is a red herring. Yes the > > "malloc(300KB)+memcpy(256KB)+free(256KB)" is wasteful, but the > > "malloc(300KB)+memcpy(200KB)+free(200KB)" would be comparably wasteful > > when you only want to preserve the first 2K, and you can make the > > decision that it would be wasteful, and that you instead just want to > > allocate a new buffer yourself and memcpy 2K, just by knowing the > > original 200KB, without any knowledge of malloc_usable_size. > > They want to know if realloc will resize the allocation in-place so > the internal memcpy will not happen. > > AIUI, what they really need is not "usable_size", but "cost estimation > for resizing allocation at pointer P to size S". Which I believe they > try to deduce from malloc_usable_size. I see. But then I doubt this is something you can reliably expect from any implementation, as at best, one would just have to assume that the target allocator works in one way and wouldn't change. This will result in a code tightly bound to a specific alocator because of the assumptions made about the library internals. This is not really the kind of contract one makes with the POSIX/C library in a portable way. So if the request really is to press every libc implementation into adopting one user's (or a few) self-made requirements, that still doesn't sound like a constructive conversation here. At this point if ones really needs micro-management of their memory, they should just implement their own allocator.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.