GNU bug report logs - #26193
[0-9] versus [[:digit:]]

Previous Next

Package: grep;

Reported by: "John P. Linderman" <jpl.jpl <at> gmail.com>

Date: Mon, 20 Mar 2017 17:00:02 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 26193 <at> debbugs.gnu.org (full text, mbox):

From: "John P. Linderman" <jpl.jpl <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 26193 <at> debbugs.gnu.org, Gnulib bugs <bug-gnulib <at> gnu.org>,
 Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#26193: [0-9] versus [[:digit:]]
Date: Wed, 22 Mar 2017 17:58:39 -0400
[Message part 1 (text/plain, inline)]
I used to use LC_ALL=C, but, as I vaguely recall, it got in the way of
dealing with UNICODE. I tried a couple LC values aimed at UNICODE and the
US, but something always went pear-shaped. I finally give up. I am
perfectly happy to suffer a tiny bit of performance, to have most things
work without thinking. A factor of 6, or 35, is not tiny, since I use grep
and friends intensely. That's how I discovered the performance problem to
begin with. Anyway, thank you for fixing my problem. I suspect that many of
us pioneers (using UNIX since 1973) have '[0-9]' wired into our fingers.

On Wed, Mar 22, 2017 at 2:01 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 03/22/2017 05:44 AM, John P. Linderman wrote:
>
>> That puts the runtimes on equal footing:
>>
>> In my measurements, P[0-9] is still a tiny bit slower if one is using
> glibc regex, due to a performance problem in glibc. You can work around it
> by configuring --with-included-regex. It's probably not worth worrying
> about, though.
>
> By the way, using LC_ALL=C should help avoid performance problems like
> these in the future, if all you're doing is something where single-byte
> pattern matching suffices.
>
>
[Message part 2 (text/html, inline)]

This bug report was last modified 8 years and 66 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.