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 13886 invoked from network); 20 Sep 2022 01:01:12 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 01:01:12 -0000 Received: (qmail 26621 invoked by uid 550); 20 Sep 2022 01:01:10 -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 26598 invoked from network); 20 Sep 2022 01:01:09 -0000 Date: Mon, 19 Sep 2022 21:00:57 -0400 From: Rich Felker To: baiyang Cc: musl Message-ID: <20220920010056.GG9709@brightrain.aerifal.cx> References: <2022091915532777412615@gmail.com> <20220919110829.GA2158779@port70.net> <874jx3h76u.fsf@oldenburg.str.redhat.com> <20220919134659.GO9709@brightrain.aerifal.cx> <2022092001404698842815@gmail.com> <2022092008254998320584@gmail.com> <20220920003811.GF9709@brightrain.aerifal.cx> <2022092008470636285288@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2022092008470636285288@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) On Tue, Sep 20, 2022 at 08:47:07AM +0800, baiyang wrote: > > Would it be possible to limit use of the list to actually requesting > > help or making reports, rather than inciting debates about what is UB > > or what the consequences of UB might be? > > You are right. > > The real question is: if we only need malloc_usable_size to return > the size actually allocated internally (not the size requested by > the user, **just as musl version 1.1 and all other libc > implementations do**), is it possible to improve its time and space > efficiency? There is no hidden "size actually allocated internally". The size you get is the size you requested. Everything else is allocator data structures *outside of the object* that the caller has no entitlement to peek or poke at, and malloc_usable_size's return value reflects that. If you want to see what portion of the time is being spent on different parts of processing the metadata, you could sit down and actually run it under perf to get a profiling report/flame graph. I'm pretty sure you'll find that the final get_nominal_size step is a small portion of the time spent. get_meta is probably the majority of the time, some of it fundamental, and some of it hardening. But don't take my word for it. Measure. One thing I can tell you definitively though: if you did what the C language (which lacks malloc_usable_size) intended you to do, and kept track of the size of your own buffer, and just used that, you would spend 0% of the time you're spending on this. You would also save the entire "several hundred ms per 10 million calls" it's costing on other malloc implementations, by just *not doing something you don't need to do*. Rich