From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id dd73ab0b for ; Wed, 4 Mar 2020 09:17:48 +0000 (UTC) Received: (qmail 24494 invoked by uid 550); 4 Mar 2020 09:17:46 -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 24469 invoked from network); 4 Mar 2020 09:17:45 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZiAvLMetNuDOrxp5wM1i2FIIhonMv/yDzTsDrGg0AW8=; b=sweeUWAvICnLopNrpKzv/9PHHYhZxeCIW856ibHnUk0B70UNfin6oC0hB5SbZdWR3U iObO7uUfIUr7jNZbFrTbUPxRqqQjaDHYagahyrV8ZFcqfYLu64S7Ht34jJaCDZRO08py zwy01gsisjr7fukOGIvPtiNC5D67isPKtpIAbIzI3NZj5/f/v2CiP3wpADswKJ4DNSNc 8JqfRgaCCUs4pPiokL+opyMB0JZPBHCmnw+GSn4dxdoHRfoh9oVwzCdCJJiLspFsj2PR GCh6ijhk42qIc+pW6TmRwg+d6LraCC/EDO6fKiNKY9CU7My3C5evfOCPPDLKTlMAZ+GY PDfA== X-Gm-Message-State: ANhLgQ1DswyM6HT6a+7hVaxRCT2YOw3GlLPC4Ied6+2X1jXUpsBJh7Jf l0AGCGlO84MQqbdKc2q9EvU= X-Google-Smtp-Source: ADFU+vttkYcx8pBA4OyPShTpujPKrxQmaGHQTu7FyUii2i+vCAkvF1ySoqZt6ei2EJeqWxEyLja0Gg== X-Received: by 2002:a2e:b163:: with SMTP id a3mr1413827ljm.233.1583313454527; Wed, 04 Mar 2020 01:17:34 -0800 (PST) Date: Wed, 4 Mar 2020 11:17:31 +0200 From: Timo Teras To: Alexander Monakov Cc: musl@lists.openwall.com Message-ID: <20200304111731.642b8b58@vostro.wlan> In-Reply-To: References: <20200303213348.10326-1-timo.teras@iki.fi> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] improve strerror speed On Wed, 4 Mar 2020 12:06:21 +0300 (MSK) Alexander Monakov wrote: > Hi, >=20 > On Tue, 3 Mar 2020, Timo Ter=C3=A4s wrote: >=20 > > change the current O(n) lookup to O(1) based on the machinery > > described in "How To Write Shared Libraries" (Appendix B). =20 >=20 > I'm curious about the background of this change, did the inefficiency > came up in practice? Yes, it's the openssl querying all possible strerrors: https://github.com/openssl/openssl/blob/master/crypto/err/err.c#L181 That makes it up to valgrind --tool=3Dcallgrind to peak the strerror_l in performance analysis on short running programs: 673,622 /data/aports/main/musl/src/musl-1.1.24/src/errno/strerror.c:strer= ror_l [/lib/ld-musl-x86_64.so.1] This change completely removes strerror from there. > > --- a/src/errno/__strerror.h > > +++ b/src/errno/__strerror.h > > @@ -1,8 +1,9 @@ > > -/* This file is sorted such that 'errors' which represent > > exceptional > > - * conditions under which a correct program may fail come first, > > followed > > - * by messages that indicate an incorrect program or system > > failure. The > > - * macro E() along with double-inclusion is used to ensure that > > ordering > > - * of the strings remains synchronized. */ > > +/* The first '0' mapping will be used for error codes that > > + * are not explicitly mentioned here. > > + * This file is included multiple times to generate struct > > + * populate it's content and create a fast lookup index to it. */ =20 >=20 > The last sentence seems to have typos ("a struct,", "its"). > I would write the comment like this: >=20 > /* The first entry is a catch-all for codes not enumerated here. > * This file is included multiple times to declare and define a > structure > * with messages, and then to define a lookup table translating error > codes > * to offsets of corresponding fields in the structure. */ >=20 > > + if (e < 0 || e >=3D sizeof(errmsgidx)/sizeof(errmsgidx[0])) > > e =3D 0; =20 >=20 > I think usually in musl such range checks are written in an > easier-to-optimize form that tests the argument in an unsigned type, > e.g. like this: >=20 > if ((size_t)e >=3D sizeof errmsgidx / sizeof *errmsgidx) e =3D 0; Thanks, will update and resend. Timo