From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14512 invoked by alias); 29 Feb 2008 00:43:27 -0000 Received: (qmail 14091 invoked by uid 48); 29 Feb 2008 00:42:44 -0000 Date: Fri, 29 Feb 2008 00:43:00 -0000 From: "egmont at gmail dot com" To: glibc-bugs@sources.redhat.com Message-ID: <20080229004244.5807.egmont@gmail.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/5807] New: strlen() not effective X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00124.txt.bz2 Most of the functions similar to strlen() that have to detect whether any bytes of an integer is zero are very efficient. However, in glibc-2.7/string/strlen.c this efficient code that's used in lots of other functions is surrounded by an #if 0, and instead a trivial code is used which exits the loop and examines each bytes separately if any of the bytes is within the range 129-255 or 0. That is roughly 15/16 of all random cases in 4-bit architecture and even more in 8-bit. Hence I think this function is hardly any more efficient than if you read one long int and then simply examined all its bytes separately. Is there any reason for the code that looks way more effective and is being used in many other source files to be commented out here? -- Summary: strlen() not effective Product: glibc Version: unspecified Status: NEW Severity: minor Priority: P3 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: egmont at gmail dot com CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=5807 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.