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
b. f. bf1...@googlemail.com writes:
Dag-Erling Smørgrav d...@des.no writes:
Does not seem to work properly is not a very useful statement. The
least you could do is provide an example.
I did provide an example, later in the same sentence that you quoted.
I forgot to answer this part. By
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)
On 2010-08-20 23:07, b. f. wrote:
The lisp category is the only category that causes a problem with the
new bsdgrep, and I didn't take the time to analyze why ( which is why
I was not more specific in my original message). 'lisp' is preceded by
'elisp', which would normally be a match for the
Dag-Erling Smørgrav wrote:
Alan Cox a...@cs.rice.edu writes:
Here is what actually puzzles me about these results. With
traditional I/O, even after the optimizations to bsdgrep, the system
time for gnugrep is still less than half that of the optimized
bsdgrep. I haven't looked at the
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 a
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
Alan Cox a...@cs.rice.edu writes:
Here is what actually puzzles me about these results. With
traditional I/O, even after the optimizations to bsdgrep, the system
time for gnugrep is still less than half that of the optimized
bsdgrep. I haven't looked at the changes, but I would have thought
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 -
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 is
Gabor Kovesdan wrote:
Yes, I'm sorry for my slow reaction, I got a flu some time ago and that
prevented me from fixing the bugs earlier. I have several fixes in my
working copy, which are being discussed with my mentor. Probably, today
or tomorrow they will be committed.
Gabor
When will
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
2010 16:42:26 +
From: David Xu davi...@freebsd.org
Subject: Re: Official request: Please make GNU grep the default
To: Gabor Kovesdan ga...@freebsd.org
Cc: delp...@freebsd.org, Andrey Chernov a...@nagual.pp.ru, Doug
Barton do...@freebsd.org, c...@freebsd.org, curr...@freebsd.org
Dag-Erling Smørgrav wrote:
There is a lesson here: people who are unsatisfied with the performance
of ${TOOL} should profile it before they start a flamefest on -current.
If you're alluding to Dougs original email, I will strictly disagree.
He found a performance issue which noone had seen or
V. T. Mueller, Continum v.t.muel...@continum.net writes:
If you're alluding to Dougs original email, I will strictly disagree.
He found a performance issue which noone had seen or brought up before
and gave feedback to Gabor in a constructive and distinctively polite
manner.
It would have
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 -
On Wednesday, August 18, 2010 5:54:41 pm Dimitry Andric wrote:
On 2010-08-18 23:12, Dimitry Andric wrote:
And one trial is not statistically valid - especially given the small
differences. How about multiple multiple trials with ministat.
The result were averages of three trials
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
On Thu, 19.08.2010 at 16:42:26 +, David Xu wrote:
Gabor Kovesdan wrote:
Yes, I'm sorry for my slow reaction, I got a flu some time ago and that
prevented me from fixing the bugs earlier. I have several fixes in my
working copy, which are being discussed with my mentor. Probably,
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
...@freebsd.org
Subject: Re: Official request: Please make GNU grep the default
To: Gabor Kovesdan ga...@freebsd.org
Cc: delp...@freebsd.org, Andrey Chernov a...@nagual.pp.ru, Doug
Barton do...@freebsd.org, c...@freebsd.org, curr...@freebsd.org
Message-ID: 4c6d5ef2.2040...@freebsd.org
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
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 the
In message: 4c6c1cfe.6060...@freebsd.org
Gabor Kovesdan ga...@freebsd.org writes:
: When reply, please remove core@ from CC, let's not bother them with
: this, I just wanted to let them know that I'm not neglecting this
: issue but if still demanded for a good reason, I'll switch back
Op 18 aug. 2010 om 18:48 heeft Gabor Kovesdan ga...@freebsd.org het volgende
geschreven:
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
On 2010-Aug-17 22:29:46 +0200, Dimitry Andric dimi...@andric.com wrote:
On 2010-08-17 18:29, Alan Cox wrote:
Try it again on a memory resident file with the MAP_PREFAULT_READ option
that is provided by this patch:
http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch
A time trial gives:
On 2010-08-18 22:52, Peter Jeremy wrote:
grep with normal mmap() 1396s
grep with prefault mmap() 1354s
grep with regular read() 1354s
Is this with uncached (ie remount the filesystem on each test) or cached
data?
This is all on the same filesystem, and the test file is
On 2010-08-18 23:12, Dimitry Andric wrote:
And one trial is not statistically valid - especially given the small
differences. How about multiple multiple trials with ministat.
The result were averages of three trials
Actually, since I kept using Doug's original grep-time-trial.sh, each of
On 2010-08-16 10:55, Dag-Erling Smørgrav wrote:
Dimitry Andric dimi...@andric.com writes:
- Uses plain file descriptors instead of struct FILE, since the
buffering is done manually anyway, and it makes it easier to support
gzip and bzip2.
It might be worth a shot adding mmap(2) support as
[Cc: list sanitized]
On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote:
On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote:
Dimitry Andric dimi...@andric.com writes:
- Uses plain file descriptors instead of struct FILE, since the
buffering is done manually anyway, and it makes
2010/8/17 Dimitry Andric dimi...@andric.com
On 2010-08-16 10:55, Dag-Erling Smørgrav wrote:
Dimitry Andric dimi...@andric.com writes:
- Uses plain file descriptors instead of struct FILE, since the
buffering is done manually anyway, and it makes it easier to support
gzip and bzip2.
On Tue, Aug 17, 2010 at 10:45 AM, Kostik Belousov kostik...@gmail.comwrote:
[Cc: list sanitized]
On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote:
On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote:
Dimitry Andric dimi...@andric.com writes:
- Uses plain file descriptors
On 2010-08-17 18:29, Alan Cox wrote:
Try it again on a memory resident file with the MAP_PREFAULT_READ option
that is provided by this patch:
http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch
A time trial gives:
grep with normal mmap() 1396s
grep with prefault mmap() 1354s
On Tue, Aug 17, 2010 at 3:29 PM, Dimitry Andric dimi...@andric.com wrote:
On 2010-08-17 18:29, Alan Cox wrote:
Try it again on a memory resident file with the MAP_PREFAULT_READ option
that is provided by this patch:
Dimitry Andric dimi...@andric.com writes:
- Uses plain file descriptors instead of struct FILE, since the
buffering is done manually anyway, and it makes it easier to support
gzip and bzip2.
It might be worth a shot adding mmap(2) support as well, i.e. when
processing an uncompressed
Since this is now well off the original topic.
On 2010-Aug-15 12:57:23 +0200, Ivan Voras ivo...@freebsd.org wrote:
This is my long-term point - it really would be beneficial to have an
alternative, richer language in base which would fall between the
categories of a good system language but far
On 2010-08-15 21:49, Dimitry Andric wrote:
...I
have attached a more complete patch that:
- Replaces the horrendously inefficient grep_fgetln() with mostly the
same implementation as the libc fgetln() function.
- Uses plain file descriptors instead of struct FILE, since the
buffering
On 2010-Aug-16 10:55:18 +0200, Dag-Erling Smørgrav d...@des.no wrote:
It might be worth a shot adding mmap(2) support as well, i.e. when
processing an uncompressed regular file, try to mmap(2) it first, and if
that fails, fall back to the plain buffered read(2) method.
Note that ZFS and mmap()
On Sun, 15 Aug 2010, Dag-Erling Smørgrav wrote:
Sean C. Farley s...@freebsd.org writes:
This should trim some time off BSD grep.
Did you actually test your patch? It makes absolutely no measurable
difference.
Yes, I saw a reduction, using the first test script Doug provided, from
36 to
Sean C. Farley s...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
Did you actually test your patch? It makes absolutely no measurable
difference.
Yes, I saw a reduction,
I didn't...
DES
--
Dag-Erling Smørgrav - d...@des.no
___
Em 2010.08.15. 21:49, Dimitry Andric escreveu:
GNU grep
Elapsed time: 57 seconds
BSD grep (original)
Elapsed time: 820 seconds (~14.4x slower than GNU grep)
BSD grep (quickfixed)
Elapsed time: 115 seconds (~2.0x slower than GNU grep)
It proves that getting rid of the
Em 2010.08.16. 16:11, Dag-Erling Smørgrav escreveu:
Sean C. Farleys...@freebsd.org writes:
Dag-Erling Smørgravd...@des.no writes:
Did you actually test your patch? It makes absolutely no measurable
difference.
Yes, I saw a reduction,
I didn't...
I also saw a
On 08/16/2010 03:42, Dimitry Andric wrote:
On 2010-08-15 21:49, Dimitry Andric wrote:
...I
have attached a more complete patch that:
- Replaces the horrendously inefficient grep_fgetln() with mostly the
same implementation as the libc fgetln() function.
- Uses plain file descriptors instead
On Sat, 14 Aug 2010, Doug Barton wrote:
...
http://people.freebsd.org/~dougb/grep-time-trial-2.sh.txt
Typical times for me, with 489 ports:
GNU grep
Elapsed time: 3 seconds
BSD grep
Elapsed time: 17 seconds
Which version of GNU grep is this that you have in /usr/local?
/bz
--
Bjoern A.
On 15 Aug 2010, at 3:12, Doug Barton wrote:
(And before anyone bothers to reply saying Use pkg_info -O for that
I'll save you the trouble. My version is from 10-20% faster. Not sure
why, don't really care.) :)
Congrats for beating the performance of a(nother) utility in base, but -
On 15 August 2010 02:45, Doug Barton do...@freebsd.org wrote:
Ivan,
I know that you mean this at least semi-humorously, however I'm going to
provide a dead-serious reply below.
Thank you for your level-headed response - it's actually better than
continuing less seriously or explosively :)
- Original Message -
From: Steve Kargl s...@troutmask.apl.washington.edu
Whereas switching the default back to GNU grep *guarantees*
neither unsophisticated nor sophosticated user will test
BSD grep.
It seems that you are letting a poor design decision with
respect to portmaster impair
- Original Message -
From: Andrew Thompson thom...@freebsd.org
On 15 August 2010 13:55, Doug Barton do...@freebsd.org wrote:
Our default grep should be significantly slower than the old grep because:
I think that new grep which is times slower than the old grep is still
in the
On Sun, Aug 15, 2010 at 12:10 PM, Steven Hartland
kill...@multiplay.co.uk wrote:
- Original Message - From: Andrew Thompson thom...@freebsd.org
On 15 August 2010 13:55, Doug Barton do...@freebsd.org wrote:
Our default grep should be significantly slower than the old grep
because:
I
On Aug 15, 2010, at 1:56 AM, Alban Hertroys wrote:
On 15 Aug 2010, at 3:12, Doug Barton wrote:
(And before anyone bothers to reply saying Use pkg_info -O for that
I'll save you the trouble. My version is from 10-20% faster. Not sure
why, don't really care.) :)
Congrats for beating the
Sean C. Farley s...@freebsd.org writes:
This should trim some time off BSD grep.
Did you actually test your patch? It makes absolutely no measurable
difference.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
On 2010-08-15 21:07, Dag-Erling Smørgrav wrote:
I built a profiling version of BSD grep and ran it with a regexp that
matches only the very last line in (my copy of) INDEX-9. The results
are pretty clear:
[I also did precisely that, and I just read your mail when I was
composing the
Em 2010.08.15. 21:07, Dag-Erling Smørgrav escreveu:
Ignore the first two lines (that's the profiling code itself). Note
that the top five lines are all in stdio, and nothing else even shows up
on the radar. I only included enough output to show where the regexp
code ranks; the complete output
In message: 894c8953-7f2f-486f-8701-a3dff65d7...@kientzle.com
Tim Kientzle t...@kientzle.com writes:
:
: On Aug 15, 2010, at 1:56 AM, Alban Hertroys wrote:
:
: On 15 Aug 2010, at 3:12, Doug Barton wrote:
:
: (And before anyone bothers to reply saying Use pkg_info -O for that
:
On Aug 15, 2010, at 12:49 PM, Dimitry Andric wrote:
So my first quick fix attempt was to replace the home-grown grep_fgetln
with fgetln(3), which is in libc. This does not support gzip and bzip2
files, but just to prove the point, it is enough. It gave the following
profiling result:
FYI:
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--56599777-398594934-1281714095=:35204
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 13 Aug 2010, Gabor Kovesdan
BSD grep
Elapsed time: 47 seconds
what about optimizing BSD grep instead?
I think this is reasonable, leave BSD grep default for a few more weeks, and
work on performance enhancements. I agree that changing the default back
for a RELEASE is probably a good idea, but the exposure to wider
why would you want to lock a file for reading anyways?
Does current bsdgrep read lock by default ?
If so, it would be better off by default, enabled by an option.
8.0-RELEASE man grep (gnu) does not mention locking.
Cheers,
Julian
--
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich
On 14-08-2010 4:35, Sam Fourman Jr. wrote:
BSD grep
Elapsed time: 47 seconds
what about optimizing BSD grep instead?
I think this is reasonable, leave BSD grep default for a few more weeks, and
work on performance enhancements. I agree that changing the default back
for a RELEASE is
On Sat, 14 Aug 2010, Julian H. Stacey wrote:
why would you want to lock a file for reading anyways?
Does current bsdgrep read lock by default ?
If so, it would be better off by default, enabled by an option.
8.0-RELEASE man grep (gnu) does not mention locking.
bsdgrep in -current does lock
On Sat, 14 Aug 2010, Julian H. Stacey wrote:
why would you want to lock a file for reading anyways?
Does current bsdgrep read lock by default ?
If so, it would be better off by default, enabled by an option.
8.0-RELEASE man grep (gnu) does not mention locking.
bsdgrep in -current
On Sat, Aug 14, 2010 at 06:23:55PM +0300, Daniel Braniss wrote:
On Sat, 14 Aug 2010, Julian H. Stacey wrote:
why would you want to lock a file for reading anyways?
Does current bsdgrep read lock by default ?
If so, it would be better off by default, enabled by an option.
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote:
Gabor,
I hope at this point it goes without saying that I have a lot of respect
I am Nth on this. Although I do a lot of l10n work in the beautefull less
bureocracy FreeBSD time and very appreciate what Gabor did, the problem is
Em 2010.08.13. 10:52, Roman Divacky escreveu:
what about optimizing BSD grep instead?
[... picking one mail from the many that suggest this ...]
The problem is that optimization is not that trivial. I think the
bottleneck is the regex library because:
1, BSD grep is so simple. There may
Em 2010.08.14. 17:53, Andrey Chernov escreveu:
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote:
Gabor,
I hope at this point it goes without saying that I have a lot of respect
I am Nth on this. Although I do a lot of l10n work in the beautefull less
bureocracy FreeBSD
On 2010-08-14 17:53, Andrey Chernov wrote:
From my point of
view importing of the latest GNU grep instead would have more benefits.
Unfortunately GNU grep switched to GPLv3 as of version 2.5.3. The last
GPLv2 version of grep is 2.5.1, which is already in our tree.
In message: 4c66c0a4.3000...@freebsd.org
Gabor Kovesdan ga...@freebsd.org writes:
: Yes, I'm sorry for my slow reaction, I got a flu some time ago and
: that prevented me from fixing the bugs earlier. I have several fixes
: in my working copy, which are being discussed with my
:
On 13.8.2010 11:34, Doug Barton wrote:
On 08/13/2010 02:08, Gabor Kovesdan wrote:
Ok, I'll take care of this soon, and make GNU grep default, again with a
knob to build BSD grep. I agree with you that we cannot allow such a big
performance drawback but I my measures only showed significant
Ivan,
I know that you mean this at least semi-humorously, however I'm going to
provide a dead-serious reply below.
On 08/14/2010 16:04, Ivan Voras wrote:
On 13.8.2010 11:34, Doug Barton wrote:
To be fair, I didn't notice a performance difference either until I
started revamping this code
On 08/14/2010 09:10, Gabor Kovesdan wrote:
Em 2010.08.13. 10:52, Roman Divacky escreveu:
what about optimizing BSD grep instead?
[... picking one mail from the many that suggest this ...]
... and responding to your message for the same reason ... :)
[Snipping the bit about why it's a
On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote:
Sophisticated users who DO care about performance and/or DO use grep in
interesting and creative ways will put up with the breakage for a while,
then switch their make.conf to use GNU grep, usually silently. Therefore
they stop
On 08/14/2010 18:34, Steve Kargl wrote:
On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote:
Sophisticated users who DO care about performance and/or DO use
grep in interesting and creative ways will put up with the breakage
for a while, then switch their make.conf to use GNU grep,
I think that new grep which is times slower than the old grep is
still in the acceptable range.
aol
you are forcing more time to be spent on the mailing list than working
the code. and many of us have to care about the license issue.
randy
On 08/14/2010 19:02, Randy Bush wrote:
I think that new grep which is times slower than the old grep is
still in the acceptable range.
aol
you are forcing more time to be spent on the mailing list than working
the code.
Not my intention at all, but I feel your pain. I really thought
Hi all,
Over the past 18 hours, I've received 22 emails in this thread.
In email number 5, sent a mere 25 minutes after the thread started, gabor@
said that he agreed that the performance penalty in BSD grep compared to
GNU grep was excessive and that he was going to revert back to having GNU
On 15 August 2010 13:55, Doug Barton do...@freebsd.org wrote:
Our default grep should be significantly slower than the old grep because:
I think that new grep which is times slower than the old grep is still
in the acceptable range.
I think that new grep which is 1000 times slower than
My $0.02 may not be worth much, but ...
On Aug 14, 2010, at 9:55 PM, Doug Barton wrote:
I was hoping to avoid commenting on this, but my feeling (and I
would be glad to be wrong about it) from reading the responses is
that there is a fair degree of knee-jerk reaction to what seems to
be
Em 2010.08.13. 10:43, Doug Barton escreveu:
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the last
time I tested those features. Thinking that
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote:
-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
On 08/13/2010 02:08, Gabor Kovesdan wrote:
Ok, I'll take care of this soon, and make GNU grep default, again with a
knob to build BSD grep. I agree with you that we cannot allow such a big
performance drawback but I my measures only showed significant
differences for very big searches and I
Doug Barton do...@freebsd.org writes:
[...]
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the last
time I tested those features. Thinking
Gabor Kovesdan wrote on 2010-08-13:
Em 2010.08.13. 10:43, Doug Barton escreveu:
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the last
time I
I wrote:
Might be worth a read, together with profiling Doug's test case if he
could tell you how to reproduce those.
Make that since he has provided the means to reproduce those. I had
read, but not realized, Doug uploaded the test case.
--
Matthias Andree
Em 2010.08.13. 13:09, Matthias Andree escreveu:
Gabor Kovesdan wrote on 2010-08-13:
Em 2010.08.13. 10:43, Doug Barton escreveu:
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that
Em 2010.08.13. 13:33, Anonymous escreveu:
Doug Bartondo...@freebsd.org writes:
[...]
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the
On Fri, 13 Aug 2010, Gabor Kovesdan wrote:
Em 2010.08.13. 10:43, Doug Barton escreveu:
My reason is simple, performance. While doing some portmaster work
recently I was regression testing some changes I made to the --index*
options and noticed that things were dramatically slower than the
99 matches
Mail list logo
