[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Sep 2022 20:12:44 +0200
From: Quentin Rameau <quinq@...th.space>
To: musl@...ts.openwall.com
Cc: "Florian Weimer" <fweimer@...hat.com>, "Rich Felker" <dalias@...c.org>
Subject: Re: The heap memory performance (malloc/free/realloc) is
significantly degraded in musl 1.2 (compared to 1.1)
> This is a good thing, we noticed it before. But we actually need a realloc that **can specify the copy range**.
>
> As in our previous example, suppose we "void* p malloc(200KB)" and "malloc_usable_size(p)" returns 256KB. For allocators such as tcmalloc, if we do "realloc(p, 300KB)", it will actually execute "malloc(300KB)+memcpy(**256KB**)+free(256KB)". But at this time, the actual business of the application layer often only needs to copy a small amount of content, such as the first 2KB of data.
So what you're actually trying to do is more clear now.
And this is something that you should do on the “application layer”,
not expect the libc to magically taking care of this.
If your application already knows it only needs to keep back only a few amount of data, do this in a wrapper, malloc(300KB), memcpy(2KB), free old memory.
If on the other hand it know it actually wants to reuse the same data but in a more vast contiguous memory, use realloc.
> Therefore, it would be great if there were additional parameters to inform realloc to just execute malloc(300KB)+memcpy(**2KB**)+free(256KB) when degenerating back to malloc+memcpy+free.
That's what your wrapper would be.
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.
