From owner-svn-src-all@FreeBSD.ORG Mon Jan 30 19:05:18 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1D3E106566C; Mon, 30 Jan 2012 19:05:18 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theravensnest.org [109.169.23.128]) by mx1.freebsd.org (Postfix) with ESMTP id 4D44A8FC16; Mon, 30 Jan 2012 19:05:17 +0000 (UTC) Received: from [192.168.0.2] (cpc1-cwma8-2-0-cust257.7-3.cable.virginmedia.com [82.20.153.2]) (authenticated bits=0) by theravensnest.org (8.14.4/8.14.4) with ESMTP id q0UJ5Go1003483 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 30 Jan 2012 19:05:17 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120118190714.GA13375@zim.MIT.EDU> Date: Mon, 30 Jan 2012 19:05:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <318F6CAA-D37E-49E9-A147-E21DE803EFB7@FreeBSD.org> References: <201111201445.pAKEjgNR096676@svn.freebsd.org> <20120118190714.GA13375@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1251.1) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r227753 - in head: contrib/gdtoa include lib/libc/gdtoa lib/libc/gen lib/libc/locale lib/libc/regex lib/libc/stdio lib/libc/stdlib lib/libc/stdtime lib/libc/string X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:05:18 -0000 On 18 Jan 2012, at 19:07, David Schultz wrote: > This patch appears to cause a large performance regression. For > example, I measured a 78% slowdown for strtol(" 42", ...). That's definitely worth taking a closer look at. I think we can cache = some things in TLS and avoid some pthread_getspecific calls. The = current code is the 'make it work' version. The 'make it fast' version = is planned... > Furthermore, the resulting static binary for a trivial program > goes from 7k to 303k, due to pulling in malloc, stdio, and all the > pthread stubs. =20 That's not ideal, but I'm not sure if it's avoidable. Is statically = linking libc something people regularly do? > Presumably the capabilities of the non-xlocale > entry points aren't appreciably changed, Well... actually they are. All of them now use the per-thread locale if = one is set, and only fall back to the global one if it isn't. The = behaviour is only unchanged if nothing in the program calls uselocale(). > so there ought to be a > way to avoid the overhead for them. Do you have any thoughts on this? Yup. A quick-and-dirty hack would be to add a flag that was set on the = first call to uselocale() and to always use the global locale if this is = not set. That should remove a lot of the overhead in cases where no one = uses the per-thread locales. =20 We can also probably store the locale in TLS, which (on platforms with = fast TLS) should speed up the lookup a bit. =20 > Some more minor issues... >=20 > It's also customary to document public APIs so that, for > instance, `man printf_l' pulls up a page with the prototype, > required #includes, and behavior. Aliasing manpages with > MLINKS as appropriate is fine; for instance, Darwin's manpages > on these functions look like a good example to follow. Yup, all of the foo_l manpages are missing. They're on my TODO, unless = any docs people want to get there first... > Finally, I'm not usually one to be picky about style, but could > you make a pass to clean things up a little bit to match the > surrounding code, wrap multiline comments to 80 columns, etc? > You've also added new copyright notices for one-line changes > (e.g., stdio/vdprintf.c, gdtoa/machdep_ldis?.c) and multiple > copyright notices in the same file (locale/collate.c), which > could be cleaned up concurrently. I'll take a look. David=