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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6411 invoked from network); 21 Sep 2022 08:42:51 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Sep 2022 08:42:51 -0000 Received: (qmail 12126 invoked by uid 550); 21 Sep 2022 08:42:48 -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 12105 invoked from network); 21 Sep 2022 08:42:48 -0000 X-Virus-Scanned: SPAM Filter at disroot.org Date: Wed, 21 Sep 2022 14:42:40 +0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1663749753; bh=9idtLUwUnkOObEaPNQmtj2NbdZBgAyKYnDec7PpQ+aw=; h=Date:From:To:Subject:References:In-Reply-To; b=c97sup9MVThuNolLtbtkTC3IuSv0Hpuz/9A6KPzzDiRHJiwbi/l9rYukIsuSIe+O1 2Ug3m9IXlTryilltJl6ypHrHlYrgWTmXahiKeABlmsgwNc8owme7O3hnfxQH/N1zVn hH9O8wIETIoIMzkqlv2B9AQF0ppK58LzrbazrCc7uS2O2qIfYVN5R1g7fU7FSL4I3v 5mR5VgLDfa3Mw3+HOnuOAO33PnLnBkqEFcsGTJc3QQS0B/wvxeHzOsP3d91n1X8m6P Dn41zCcDZMuHyqmKwqygfeOTzzxkdKx6mggSeFmiR50EBz5nxeamTChct8hdAWbkr2 P4eiUJOV2UIrA== From: NRK To: musl@lists.openwall.com Message-ID: <20220921084240.rg7r2img5axurbdg@gen2.localdomain> References: <874jx2phqm.fsf@oldenburg.str.redhat.com> <2022092101393822582117@gmail.com> <20220920201244.4f40362e.quinq@fifth.space> <20220920181905.GR9709@brightrain.aerifal.cx> <2022092102351588157126@gmail.com> <2022092104455700962839@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2022092104455700962839@gmail.com> Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) On Wed, Sep 21, 2022 at 04:45:59AM +0800, baiyang wrote: > Yes, we will adapt as many allocators as possible to make our software > more portable and adaptable. > > Of course, we also respect and understand the author's considerations > and trade-offs, and have avoided calling malloc_usable_size for musl's > mallocng in our software. Here's a better idea, malloc (and malloc_usable_size) cannot be slow if you never call it; so just skip it all together and grab the needed pages straight from the kernel (mmap(2) on linux/posix and on windows I think it's VirtualAlloc). The malloc API was designed for ease of use, not performance. And it's evident from the fact that user has no control over malloc's metadata. And what you're doing with malloc_usable_size() is not an "optimization", it's a heuristic at best and hack that'll actually *pessimize* at worse. Proof? This very thread. Also malloc_usable_size() does not tell you anything about weather realloc will grow in place (or avoid copy entirely via virtual address space shenanigans). If you need such fine grained control then you're using the wrong API, you either need to manage your memory directly or find an allocator library which *actually* (as in documented in the API contract) offers such control rather than relying on unreliable heuristics. - NRK