From owner-cvs-src@FreeBSD.ORG Sat Apr 2 18:57:08 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B82CF16A4CE; Sat, 2 Apr 2005 18:57:08 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D63C43D2D; Sat, 2 Apr 2005 18:57:08 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j32Iv60b019242; Sat, 2 Apr 2005 13:57:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j32Iv6cp019241; Sat, 2 Apr 2005 13:57:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sat, 2 Apr 2005 13:57:06 -0500 From: David Schultz To: src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Message-ID: <20050402185706.GA19208@VARK.MIT.EDU> Mail-Followup-To: src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200504021852.j32IqjhR031587@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504021852.j32IqjhR031587@repoman.freebsd.org> Subject: Re: cvs commit: src/lib/libc/string strcspn.c strspn.c src/sys/libkern strspn.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2005 18:57:08 -0000 On Sat, Apr 02, 2005, David Schultz wrote: > das 2005-04-02 18:52:44 UTC > > FreeBSD src repository > > Modified files: > lib/libc/string strcspn.c strspn.c > sys/libkern strspn.c > Log: > Replace the current strspn() and strcspn() with significantly faster > implementations inspired by the ones in DragonFly. Unlike the > DragonFly versions, these have a small data cache footprint, and my > tests show that they're never slower than the old code except when the > charset or the span is 0 or 1 characters. This implementation is > generally faster than DragonFly until either the charset or the span > gets in the ballpark of 32 to 64 characters. BTW, anyone know a good reason why we have optimized string functions (e.g. strcmp(), strcpy()) in libc, but not in libkern? In testing strcmp(s, s), I found that the libc version on i386 is 11% faster when s has length 1 and 4% faster when s has length 400. The kernel has many consumers of these functions, but maybe their performance is irrelevant in the grand scheme of things. Certainly things like bcopy and bswap are more important...