public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "egmont at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/5807] New: strlen() not effective
Date: Fri, 29 Feb 2008 00:43:00 -0000	[thread overview]
Message-ID: <20080229004244.5807.egmont@gmail.com> (raw)

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.


             reply	other threads:[~2008-02-29  0:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  0:43 egmont at gmail dot com [this message]
2008-03-02  3:30 ` [Bug libc/5807] " carlos at codesourcery dot com
2008-03-02  3:34 ` carlos at codesourcery dot com
2008-03-02 15:12 ` carlos at codesourcery dot com
2008-04-17 19:56 ` stas dot yakovlev at gmail dot com
2008-04-22 13:04 ` carlos at codesourcery dot com
2008-04-23 15:49 ` stas dot yakovlev at gmail dot com
2009-03-15  8:50 ` drepper at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080229004244.5807.egmont@gmail.com \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).