From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6311 invoked from network); 20 Sep 2022 18:26:27 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 18:26:27 -0000 Received: (qmail 30113 invoked by uid 550); 20 Sep 2022 18:26:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30090 invoked from network); 20 Sep 2022 18:26:24 -0000 Date: Tue, 20 Sep 2022 21:26:10 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com cc: Quentin Rameau , Florian Weimer In-Reply-To: <20220920181905.GR9709@brightrain.aerifal.cx> Message-ID: References: <2022091915532777412615@gmail.com> <20220919110829.GA2158779@port70.net> <874jx3h76u.fsf@oldenburg.str.redhat.com> <20220919134659.GO9709@brightrain.aerifal.cx> <874jx2phqm.fsf@oldenburg.str.redhat.com> <2022092101393822582117@gmail.com> <20220920201244.4f40362e.quinq@fifth.space> <20220920181905.GR9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) On Tue, 20 Sep 2022, Rich Felker wrote: > 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. Alexander