Kyle Evans wrote:
> Alright, fine, be that way. :-) Try this on top of the existing patch:
Sorry! I have this knack of (accidentally) stumbling upon weird-case bugs
that usually don't affect anyone! :-)
> https://people.freebsd.org/~kevans/grep-color-addition.diff
Brilliant That all
On 9/29/23 15:37, Kyle Evans wrote:
On 9/29/23 13:25, Jamie Landeg-Jones wrote:
Jamie Landeg-Jones wrote:
Brilliant! Thanks for the quick response and fix. It works fine for me -
I've not managed to break it again :-)
Famous last words
"grep -v" now produces duplicate
On 9/29/23 13:25, Jamie Landeg-Jones wrote:
Jamie Landeg-Jones wrote:
Brilliant! Thanks for the quick response and fix. It works fine for me -
I've not managed to break it again :-)
Famous last words
"grep -v" now produces duplicate lines! e.g. :
Alright, fine, be that wa
Jamie Landeg-Jones wrote:
> Brilliant! Thanks for the quick response and fix. It works fine for me -
> I've not managed to break it again :-)
Famous last words....
"grep -v" now produces duplicate lines! e.g. :
| % grep -v sdjdjdjd /COPYRIGHT|head
| # @(#)COPYRIGHT
Kyle Evans wrote:
> I think this is what we want:
>
> https://people.freebsd.org/~kevans/grep-color.diff
Brilliant! Thanks for the quick response and fix. It works fine for me -
I've not managed to break it again :-)
> Basically, for --color with . we actually get each individu
On 9/27/23 22:34, Greg 'groggy' Lehey wrote:
On Wednesday, 27 September 2023 at 22:30:43 -0500, Kyle Evans wrote:
On 9/27/23 21:40, Jamie Landeg-Jones wrote:
When using color=always and a regex of '.' (for example), output lines
are duplicated.
$ grep --version
grep (BSD grep, GNU compatible
On Wednesday, 27 September 2023 at 22:30:43 -0500, Kyle Evans wrote:
> On 9/27/23 21:40, Jamie Landeg-Jones wrote:
>> When using color=always and a regex of '.' (for example), output lines
>> are duplicated.
>>
>> $ grep --version
>> grep (BSD grep, GNU co
On 9/27/23 21:40, Jamie Landeg-Jones wrote:
When using color=always and a regex of '.' (for example), output lines
are duplicated.
$ grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD
E.G.:
$ grep --color=always . /etc/fstab
Cheers, Jamie
I think this is what we want:
https
When using color=always and a regex of '.' (for example), output lines
are duplicated.
$ grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD
E.G.:
$ grep --color=always . /etc/fstab
Cheers, Jamie
On 2021-Feb-17, at 11:44, Kyle Evans wrote:
> On Tue, Feb 16, 2021 at 7:29 PM Kyle Evans wrote:
>>
>> On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
>> wrote:
>>>
>>> I historically on occasion have done something like:
>>>
On Tue, Feb 16, 2021 at 7:29 PM Kyle Evans wrote:
>
> On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
> wrote:
> >
> > I historically on occasion have done something like:
> >
> > # grep -rI ... /
> >
> > in order to find all inst
On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
wrote:
>
> I historically on occasion have done something like:
>
> # grep -rI ... /
>
> in order to find all instances of a text, including
> in build trees and such. I now find that I need to
> do something
I historically on occasion have done something like:
# grep -rI ... /
in order to find all instances of a text, including
in build trees and such. I now find that I need to
do something more like (using a more specific
example):
# grep -rI --exclude-dir /dev '#define.*__FreeBSD_version
On Thu, May 3, 2018 at 12:54 PM, Stefan Esser <s...@freebsd.org> wrote:
> Am 03.05.18 um 17:28 schrieb Kyle Evans:
>> On Thu, May 3, 2018 at 10:19 AM, Stefan Esser <s...@freebsd.org> wrote:
>>> Am 03.05.18 um 16:41 schrieb Kyle Evans:
>>>> Hmm... what
Am 03.05.18 um 17:28 schrieb Kyle Evans:
> On Thu, May 3, 2018 at 10:19 AM, Stefan Esser <s...@freebsd.org> wrote:
>> Am 03.05.18 um 16:41 schrieb Kyle Evans:
>>> Hmm... what does `grep -V` look like, just to confirm?
>>
>> Ah, yes, good point ...
>>
>
Am 03.05.18 um 16:41 schrieb Kyle Evans:
Hi Kyle,
thank you for the fast reply. You were right to request grep -V output,
but see below ... ;-)
> On Thu, May 3, 2018 at 9:08 AM, Stefan Esser <s...@freebsd.org> wrote:
>> The first "grep" needs 3.5 seconds to finish on
with test data that can be fetched
> from:
>
> https://people.freebsd.org/~se/grep-test.txz
>
> The script uses "grep -v -f patternfile datafile" to select from datafiles
> the lines that are not matched by the contents of patternfile:
>
> #-
Hi all,
while working on a new portmaster version, I found that bsdgrep is much
faster in an UTF-8 locale than in the C locale, much to my surprise.
I have uploaded a small shell-script with test data that can be fetched
from:
https://people.freebsd.org/~se/grep-test.txz
The script
svn status
> > ? 7.diff
> > ? decl.c.diff
> > ? gcc/fortran/old
> > ? gcc/fortran/pr38351.diff
> > ? gcc/fortran/pr41922.diff
> > ? gcc/fortran/pr69860.diff
> > ? trans-decl.c.diff
> > ? typescript
> > ?
gcc/fortran/pr38351.diff
> ? gcc/fortran/pr41922.diff
> ? gcc/fortran/pr69860.diff
> ? trans-decl.c.diff
> ? typescript
> ? z1.diff
> troutmask:sgk[202] svn status | grep -v -E ^\?
> Segmentation fault (core dumped)
> troutmask:sgk[203] svn stat
? typescript
? z1.diff
troutmask:sgk[202] svn status | grep -v -E ^\?
Segmentation fault (core dumped)
troutmask:sgk[203] svn status | grep -v -E ^"\?"
troutmask:sgk[204] exit
exit
Script done on Sun Jul 31 08:31:54 2016
The core dump happens with both tcsh and sh.
The follo
FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24
12:33:51 UTC 2011 r...@ran.psg.com:/usr/obj/usr/src/sys/RAN amd64
% echo foo | grep foo
%
What about 'grep -V'? Or 'which grep'?
turns out that a zero length grep had been installed
updated to new sources, rebuilt
On 2011.12.28. 23:35, Randy Bush wrote:
FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24 12:33:51
UTC 2011 r...@ran.psg.com:/usr/obj/usr/src/sys/RAN amd64
% echo foo | grep foo
%
What about 'grep -V'? Or 'which grep'?
Gabor
FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24 12:33:51
UTC 2011 r...@ran.psg.com:/usr/obj/usr/src/sys/RAN amd64
% echo foo | grep foo
%
so i am csupping hoping to pick up the fix. but what do i need to do so
that the sucker can build a new kernel and world?
randy
On 12/28/2011 14:35, Randy Bush wrote:
FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24 12:33:51
UTC 2011 r...@ran.psg.com:/usr/obj/usr/src/sys/RAN amd64
% echo foo | grep foo
%
so i am csupping hoping to pick up the fix.
I'm using pretty recent -current
% echo foo | grep foo
%
I'm using pretty recent -current, and it works for me. Are you by any
chance using bsdgrep? (it's not the default)
not to my knowledge
If you haven't enabled the option for bsdgrep in src.conf then do the
same thing in /usr/src/gnu/usr.bin/grep.
make cleandir
bsdgrep works, grep does not
% echo foo | bsdgrep foo
foo
% echo foo | grep foo
%
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr
On Thu, 29 Dec 2011, Randy Bush wrote:
bsdgrep works, grep does not
% echo foo | bsdgrep foo
foo
% echo foo | grep foo
%
Make sure you do not have an alias or function for grep. I have once or
twice in the past inadvertently created aliases or functions for grep
that did nothing
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/tui/tui-source.c
cc1: warnings being treated as errors
/usr/src/usr.bin/grep/regex/tre-fastmatch.c: In function 'tre_match_fast':
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:961: warning: comparison of
unsigned expression 0 is always
/binutils/bfd -std=gnu99
-fstack-protector -c
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/tui/tui-source.c
cc1: warnings being treated as errors
/usr/src/usr.bin/grep/regex/tre-fastmatch.c: In function 'tre_match_fast':
/usr/src/usr.bin/grep/regex/tre-fastmatch.c:961: warning
On 10/05/11 10:48, I wrote:
Does this look right?
! ts = ((long)u - v 0) ? 0 : (u - v); \
Doh! It should probably be ..
ts = ((long)(u - v) 0) ? 0 : (u - v);
___
freebsd-current@freebsd.org mailing list
On Wed, 5 Oct 2011, Michael Butler wrote:
On 10/05/11 10:48, I wrote:
Does this look right?
! ts = ((long)u - v 0) ? 0 : (u - v); \
Doh! It should probably be ..
ts = ((long)(u - v) 0) ? 0 : (u - v);
This is definitely incorrect.
Consider the case where u = (int)INT_MAX, v =
than Boyer-Moore for small numbers of search terms, since
it scans the entire input. I don't see the point in using it in
grep, because grep already has an algorithm for constructing finite
state machines: regcomp(3).
especially those that could be useful for fgrep functionality
Not entirely
Mike Haertel m...@ducky.net writes:
Dag-Erling Smørgrav d...@des.no writes:
You don't really need to isolate the containing line unless you have
an actual match, do you?
Theoretically no. However, suppose the pattern was /foo.*blah/.
The Boyer-Moore search will be for blah, since that's
Em 2010.08.19. 8:41, Doug Barton escreveu:
The performance is now almost comparable to GNU grep.
I think you're using a very liberal definition of comparable.
Ok, comparable for the casual cases but not generally comparable.
I think with this, BSD grep may remain default if no other
Em 2010.08.19. 23:42, b. f. escreveu:
Gabor:
One more thing to look into, in addition to the context problems,
ndisgen breakage, and problems on certain file systems:
At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU grep), and has broken
Em 2010.08.21. 4:31, Mike Haertel escreveu:
Hi Gabor,
I am the original author of GNU grep. I am also a FreeBSD user,
although I live on -stable (and older) and rarely pay attention
to -current.
However, while searching the -current mailing list for an unrelated
reason, I stumbled across
regex library.
Yes. Oniguruma is slow, Google RE2 only supports Perl and fgrep syntax
but not standard regex and Plan 9 implementation iirc only supports
fgrep syntax and Unicode but not wchar_t in general.
The key comment in Mike's GNU grep notes is the one about not
breaking into lines
. By example, I mean an actual grep command
line and sample input that demonstrates the problem, the smaller the
better:
% echo elisp lisp | grep -w lisp echo good || echo bad
elisp lisp
good
% echo elisp lisp | grep -wq lisp echo good || echo bad
bad
No idea what causes it, but a quick grep (hah
I saw the discussion on this list with the subject why GNU grep is
fast and I thought I would contribute to a discussion of the
correctness of the POSIX regular expressions.
Gabor wrote:
I believe Gabor is considering TRE for a good replacement regex library.
Yes. Oniguruma is slow, Google RE2
.
Luckily grep does not need the captured subexpressions, and thus does
not need the complexity that comes from the ideas behind TRE. [etc]
I think grep does potentially need the captured subexpressions, for eg:
\([abc]\)99\1
matching eg b99b
--
Bob Bishop
r...@gid.co.uk
with the operating system.
Luckily grep does not need the captured subexpressions, and thus does
not need the complexity that comes from the ideas behind TRE. [etc]
I think grep does potentially need the captured subexpressions, for eg:
\([abc]\)99\1
matching eg b99b
That would be basic
Hi all,
there are some consequences that we can see from the grep case. Here I'd
like to add a summary, which raises some questions. All comments are
welcome.
1, When grep entered -CURRENT and bugs were found I immediately got kind
bug reports and sharp criticism, as well. According to my
Dag-Erling Smørgrav d...@des.no writes:
No idea what causes it, but a quick grep (hah!) for qflag turns up the
following horror:
/* Find out the correct return value according to the
results and the command line option. */
exit(c ? (notfound ? (qflag ? 0 : 2) : 0
.
The target succeeds as expected with GNU grep.
Can you please try the following patch? I think this solves more than
one problem in bsdgrep's logic, but it needs to be reviewed by Gabor and
others.
In usr.bin/grep/util.c, in the function procline(), there is the
following fragment:
290
On Aug 23, 2010, at 9:04 AM, Gabor Kovesdan wrote:
Hi all,
there are some consequences that we can see from the grep case. Here I'd like
to add a summary, which raises some questions. All comments are welcome.
1, When grep entered -CURRENT and bugs were found I immediately got kind bug
at the changes, but I would have thought
the system time for gnugrep and bsdgrep would be almost the same.
Two reasons:
1) BSD grep does tons of unnecessary memory-to-memory copy operations in
grep_fgetln().
2) GNU grep has its own highly optimized regex code.
Umm, not really. Notice that I
On Mon, Aug 23, 2010 at 5:04 PM, Gabor Kovesdan ga...@freebsd.org wrote:
4, We really need a good regex library. From the comments, it seems there's
no such in the open source world. GNU libregex isn't efficient because GNU
grep uses those workarounds that Mike kindly pointed out. Oniguruma
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far ahead it can skip in the input whenever
it finds a non-matching character.
Boyer-Moore is for fixed
In article 86k4nikglg@ds4.des.no you write:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far ahead it can skip in the input whenever
it finds a non
2010/8/22 Dag-Erling Smørgrav d...@des.no:
Amen. The current bottleneck in BSD grep is the memchr() that looks for
'\n' in the input buffer.
FYI I actually have a rewritten memchr() which is faster than the
current one here:
http://people.freebsd.org/~delphij/for_review/memchr.c
Review
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks first
for the final letter of the target string, and uses a lookup table to
tell it how far ahead it can skip in the input whenever it finds
* Mike Haertel m...@ducky.net wrote:
Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking
for newlines would slow grep down by a factor of several times,
because to find the newlines it would have to look at every byte!
I think that implementing a simple fgrep boils down to mmap
On Aug 22, 2010, at 8:02 AM, Garrett Wollman wrote:
In article 86k4nikglg@ds4.des.no you write:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far
the
matched line. (I'm not sure whether FreeBSD supports any character
encodings that would be ambiguous in that way.) I don't think this
was considered an issue when Mike Haertel was developing GNU grep.
It seems reasonable to implement BMG or some other fast search in
memmem(). Note that if you
On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote:
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks first for
the final letter of the target string, and uses a lookup table to tell it
how far
Dag-Erling Sm�rgrav d...@des.no writes:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
table to tell it how far ahead it can skip in the input whenever
it finds a non
fed it. I believe it is less efficient than
Boyer-Moore for small numbers of search terms, since it scans the entire
input. I don't see the point in using it in grep, because grep already
has an algorithm for constructing finite state machines: regcomp(3).
2. http://en.wikipedia.org/wiki/Rabin
Mike Haertel m...@ducky.net writes:
For example if your regex is /foo.*bar/, the initial Boyer-Moore search
is (probably) searching for foo.
If the initial search succeeds, GNU grep isolates the containing line,
and then runs the full regex matcher on that line to make sure.
You don't really
Dag-Erling Smørgrav d...@des.no writes:
Mike Haertel m...@ducky.net writes:
For example if your regex is /foo.*bar/, the initial Boyer-Moore search
is (probably) searching for foo.
If the initial search succeeds, GNU grep isolates the containing line,
and then runs the full regex
machine that will match
either of the search strings you fed it. I believe it is less
efficient than Boyer-Moore for small numbers of search terms, since it
scans the entire input. I don't see the point in using it in grep,
because grep already has an algorithm for constructing finite state
On Sun, 22 Aug 2010, Tim Kientzle wrote:
On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote:
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel m...@ducky.net writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string
That's a good read for other things as Mike, thanks for taking the
time to pass on this knowledge :)
- Original Message -
From: Mike Haertel m...@ducky.net
To: ga...@freebsd.org
Anyway, just FYI, here's a quick summary of where GNU grep gets
its speed. Hopefully you can carry
2010/8/19 Dag-Erling Smørgrav d...@des.no:
time seconds seconds calls ms/call ms/call name
38.8 0.03 0.03 12717 0.00 0.00 memchr [5]
35.6 0.07 0.03 395 0.08 0.08 _read [6]
16.4 0.08 0.01 0 100.00% _mcount
Doug Barton do...@freebsd.org writes:
There are 2 questions, did I do the right thing, and how should people
report problems in general. As for myself, while I have some facility
in C it's not my strong suit. Yes, I could have produced a profiling
version of grep, but it would have taken me
On 2010-08-20 11:10, Dag-Erling Smørgrav wrote:
If you have profiling libraries installed, you can build a profiling
version of grep (or any program) like so:
% cd /usr/src/usr.bin/grep
% make clean
% make DEBUG_FLAGS=-pg -g -DNO_SHARED
Do *not make install, because the result will be dog
Adrian Chadd adr...@freebsd.org writes:
I've just looked at grep_fgetln(). Surely memchr() isn't required there.
Of course it is, how else are you going to locate the '\n'? OTOH, I'm
not sure grep_fgetln() is needed at all.
DES
--
Dag-Erling Smørgrav - d...@des.no
2010/8/20 Dag-Erling Smørgrav d...@des.no:
Adrian Chadd adr...@freebsd.org writes:
I've just looked at grep_fgetln(). Surely memchr() isn't required there.
Of course it is, how else are you going to locate the '\n'? OTOH, I'm
not sure grep_fgetln() is needed at all.
It seems a bit strange
Adrian Chadd adr...@freebsd.org writes:
Have you tried this in pmc?
No. I can't figure out how to use pmcstat, but I did find a bug in it:
if you specify an output file with -o, but the command line is otherwise
incomplete or incorrect, it will print usage information to the output
file instead
the system time for gnugrep and bsdgrep would be almost the same.
Two reasons:
1) BSD grep does tons of unnecessary memory-to-memory copy operations in
grep_fgetln().
2) GNU grep has its own highly optimized regex code.
DES
--
Dag-Erling Smørgrav - d...@des.no
b. f. bf1...@googlemail.com writes:
At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU grep),
Does not seem to work properly is not a very useful statement. The
least you could do is provide an example.
DES
--
Dag-Erling Smørgrav - d
On 8/20/10, Dag-Erling Smørgrav d...@des.no wrote:
b. f. bf1...@googlemail.com writes:
At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU grep),
Does not seem to work properly is not a very useful statement. The
least you could do
Hi Gabor,
I am the original author of GNU grep. I am also a FreeBSD user,
although I live on -stable (and older) and rarely pay attention
to -current.
However, while searching the -current mailing list for an unrelated
reason, I stumbled across some flamage regarding BSD grep vs GNU grep
On 08/18/2010 10:48, Gabor Kovesdan wrote:
I've just committed a patch with the kind help of Dimitry Andric,
which gives BSD grep a huge performance boost.
Agreed, as I reported earlier.
The performance is now almost comparable to GNU grep.
I think you're using a very liberal definition
will the grep -H print file name for me ? it is rather painful
that the feature is missing. :-(
So I can not use it with find:
find . -exec grep -H {} world \;
I don't know which file contains the word world.
Regards,
David Xu
___
freebsd-current
in the multi file case, but it
seems to do quite well.
./grep-time-trial.sh
GNU grep 2.5.4
Elapsed time: 2 seconds
GNU grep 2.5.1-FreeBSD (base on 8.1-RELEASE)
Elapsed time: 2 seconds
BSD grep ( from ports 2.5.1 )
Elapsed time: 48 seconds
ack 1.92 ( perl 5.8.9 )
Elapsed time: 4 seconds
Regards
M. Warner Losh i...@bsdimp.com writes:
So making it default turned out well in the end. Sure, there was pain
involved (but this is current), but making it default exposed the pain
that would otherwise have gone unnoticed. The big hue and cry, while
excessive at times, did result in people
Doug Barton do...@freebsd.org writes:
I'm not going to re-state my opinion here except to say it hasn't
changed. Even if the performance were not an issue I think the bugs
mentioned below combined with your 4-day absence should also have been
considerations. However, in regards to this
Hi,
GNU grep is OK. However standard BSD grep also work:
find . -exec grep -i world {} /dev/null \;
or even:
find . -exec grep -in world {} /dev/null \;
if you want linenumbers ...
hth
Stein Morten
On Aug 19, 2010, at 11:29, freebsd-current-requ...@freebsd.org wrote:
Date: Thu, 19 Aug
, and contributes to what makes this
community stand out from others.
In other words: as long as there are unresolved issues, the default
should be set to GNU grep. This doesn't stop anyone from improving the
BSD grep we're all waiting for. It only does good to those who rely on
using grep
been far more constructive and distinctively polite to
take ten minutes to build and run a profiling version of grep, and
include the results in the OP.
I would also second, that changing back the default immediately then
would have been the better choice.
No, it would only have ensured that nobody
Dag-Erling Smørgrav wrote:
In other words: as long as there are unresolved issues, the default
should be set to GNU grep. This doesn't stop anyone from improving the
BSD grep we're all waiting for. It only does good to those who rely on
using grep - expecting correctness and speed.
Based on my
V. T. Mueller, Continum v.t.muel...@continum.net writes:
Dag-Erling Smørgrav d...@des.no writes:
Based on my 12 years of experience in this project, you are very,
very wrong.
An 'argumentation' like the above is simply a killer phrase that ends
every discussion.
An 'argumentation' like the
+---[ V. T. Mueller, Continum ]--
|
| In other words: as long as there are unresolved issues, the default
| should be set to GNU grep. This doesn't stop anyone from improving the
| BSD grep we're all waiting for. It only does good to those who rely on
| using grep
Actually, since I kept using Doug's original grep-time-trial.sh, each of
the three 'trials' consisted of running grep 100 times, and the listed
time was the total elapsed time for those 100 runs. So I assume that
will reasonably average out the differences between each individual run?
You need
Gabor Kovesdan ga...@freebsd.org writes:
I've just committed a patch with the kind help of Dimitry Andric,
which gives BSD grep a huge performance boost. The performance is now
almost comparable to GNU grep.
Not quite, as Doug pointed out. I don't know what benchmark you're
using, but I'm
On 2010-08-17 23:24, Alan Cox wrote:
So normal mmap is ~3% slower, and prefault mmap does not seem to make
any measurable difference. I guess the added complexity is not really
worth it, for now.
Do you know what fraction of this time is being spent in the kernel?
I ran 100 trials again,
On Thursday 19 August 2010 15:38:54 Dag-Erling Smørgrav wrote:
Gabor Kovesdan ga...@freebsd.org writes:
I've just committed a patch with the kind help of Dimitry Andric,
which gives BSD grep a huge performance boost. The performance is
now almost comparable to GNU grep.
Not quite, as Doug
Dimitry Andric wrote:
On 2010-08-17 23:24, Alan Cox wrote:
So normal mmap is ~3% slower, and prefault mmap does not seem to make
any measurable difference. I guess the added complexity is not really
worth it, for now.
Do you know what fraction of this time is being spent in the
, today
or tomorrow they will be committed.
Gabor
When will the grep -H print file name for me ? it is rather painful
that the feature is missing. :-(
So I can not use it with find:
find . -exec grep -H {} world \;
I don't know which file contains the word world.
Workaround:
find
On 08/19/2010 04:13, Dag-Erling Smørgrav wrote:
It would have been far more constructive and distinctively polite to
take ten minutes to build and run a profiling version of grep, and
include the results in the OP.
Meta-comment first. des and I are both people of strong opinions, and we
agree
On 2010-08-19 18:42, David Xu wrote:
When will the grep -H print file name for me ? it is rather painful
that the feature is missing. :-(
So I can not use it with find:
find . -exec grep -H {} world \;
I don't know which file contains the word world.
I think you mean:
find . -exec
Gabor:
One more thing to look into, in addition to the context problems,
ndisgen breakage, and problems on certain file systems:
At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU grep), and has broken the
'check-categories' target (and hence
On Thursday, August 19, 2010 10:12:11 am Dimitry Andric wrote:
On 2010-08-17 23:24, Alan Cox wrote:
So normal mmap is ~3% slower, and prefault mmap does not seem to make
any measurable difference. I guess the added complexity is not really
worth it, for now.
Do you know what fraction
But I think BSD grep should be compatible with GNU grep,
because almost all scripts are written for GNU grep before
BSD grep appears, it is not practical to rewrite all existing
scripts. Anyway, thanks for your help.
David Xu
Stein Morten Sandbech wrote:
Hi,
GNU grep is OK. However standard
Hello, Gabor.
You wrote 14 августа 2010 г., 20:10:56:
2, GNU grep uses internal optimizations to get that performance. I think
it's a wrong approach because the regex library itself should be
optimized instead to keep BSD grep clean and simple and to provide the
same efficiency for all
On Thu, Aug 19, 2010 at 09:42:01PM +, b. f. wrote:
Gabor:
One more thing to look into, in addition to the context problems,
ndisgen breakage, and problems on certain file systems:
At r211506, 'grep -wq' does not seem to work properly (in the very
least, it is not the same as with GNU
Hi Gabor and others,
As Gabor committed r211364, bsdgrep now works nicely with tail -f.
http://svn.freebsd.org/changeset/base/211364
Thank you very much.
--
kuro
___
freebsd-current@freebsd.org mailing list
Em 2010.08.18. 7:42, poyop...@puripuri.plala.or.jp escreveu:
Hi Gabor and others,
As Gabor committed r211364, bsdgrep now works nicely with tail -f.
http://svn.freebsd.org/changeset/base/211364
Thank you very much.
Acknowledgements also go to you and other users. Without quality
feedback I
Em 2010.08.13. 10:43, Doug Barton escreveu:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gabor,
I hope at this point it goes without saying that I have a lot of respect
for the work you've done on BSD grep, and I've already told you that I
think you're very courageous for taking
1 - 100 of 235 matches
Mail list logo
