John-Mark Gurney wrote:
right now, I'm trying to think of a way to eliminate the fgetln searching
for end of line... of course this would eliminate some of the simplicity
of design, but we can get a BIG speed increase if we simply don't scan for
the new line unless we NEED to... and if we
On Fri, 30 Jul 1999 22:07:26 -0400, Tim Vanderhoek wrote:
b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null
b$ time grep '(vt100)|(printer)' longfile /dev/null
You think that's fair? Surely you can't expect Jamie's extended regex
support to outperform GNU's simple regex support?
On Sat, Jul 31, 1999 at 11:56:16PM +0200, Sheldon Hearn wrote:
b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null
b$ time grep '(vt100)|(printer)' longfile /dev/null
You think that's fair? Surely you can't expect Jamie's extended regex
support to outperform GNU's simple regex
On Sat, 31 Jul 1999, Tim Vanderhoek wrote:
I rather hope that the rumoured newer version of H. Spencer's regex
lib is faster... Being as slow for that pattern as it is has got to
be a bug of some sort... It's actually faster to scan the file twice,
once for the first string and then for
John-Mark Gurney wrote:
right now, I'm trying to think of a way to eliminate the fgetln searching
for end of line... of course this would eliminate some of the simplicity
of design, but we can get a BIG speed increase if we simply don't scan for
the new line unless we NEED to... and if we
On Fri, 30 Jul 1999 22:07:26 -0400, Tim Vanderhoek wrote:
b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null
b$ time grep '(vt100)|(printer)' longfile /dev/null
You think that's fair? Surely you can't expect Jamie's extended regex
support to outperform GNU's simple regex support? :-)
On Sat, Jul 31, 1999 at 11:56:16PM +0200, Sheldon Hearn wrote:
b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null
b$ time grep '(vt100)|(printer)' longfile /dev/null
You think that's fair? Surely you can't expect Jamie's extended regex
support to outperform GNU's simple regex
On Sat, 31 Jul 1999, Tim Vanderhoek wrote:
I rather hope that the rumoured newer version of H. Spencer's regex
lib is faster... Being as slow for that pattern as it is has got to
be a bug of some sort... It's actually faster to scan the file twice,
once for the first string and then for the
James Howard [EMAIL PROTECTED] writes:
DES tells me he has a new version (0.10) which mmap()s. It supposedly
cuts the run time down significantly, I do not have the numbers in front
of me. Unfortunetly he has not posted this version yet so I cannot
download it and run it myself.
It's in
John-Mark Gurney [EMAIL PROTECTED] writes:
it was VERY simple to do... and attached is the patch... this uses the
option REG_STARTEND to do what the copy was trying to do... all of the
code to use REG_STARTEND was already there, it just needed to be enabled..
Funnily, I experience a
John-Mark Gurney wrote:
ok, I just made a patch to eliminate the copy that was happening in
procfile, and it sped up a grep of a 5meg termcap from about 2.9sec
down to .6 seconds... this includes time spent profiling the program..
GNU grep w/o profiling only takes .15sec so we ARE getting
"Daniel C. Sobral" [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav wrote:
To be precise, I experience a 30% decrease in system time and a 100%
increase in user time when I use RE_STARTEND and eliminate the
malloc() / memcpy() calls in procfile().
Could you please test my patch that removes
"Daniel C. Sobral" [EMAIL PROTECTED] writes:
Could you please test my patch that removes malloc() but bot
memcpy()? Here it is again, though against an old version:
Bingo. REG_STARTEND is significantly more expensive than memcpy().
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To
On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote:
I said that I did not care whether the thing is inside or outside
the regexp library.
Yes, although I think at this point it's obvious we're coming at this
discussion from fairly different perspectives. By the time you
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
it was VERY simple to do... and attached is the patch... this uses the
option REG_STARTEND to do what the copy was trying to do... all of the
code to use REG_STARTEND was already there, it just needed to be enabled..
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
Funnily, I experience a near-doubling of running time with similar
patches.
Incidentally, it seems that it's not possible to assume that our
regex library is even anywhere in the same league as the GNU regex
library.
b$
Tim Vanderhoek vand...@ecf.utoronto.ca writes:
I do. Still far too slow. I'll work on this tomorrow, since that
seems the only way to convince people that mmap is not such a big
win. :-(
mmap() gives a fourfold speed increase. I call that a big win.
I have a few other ideas which will make
James Howard howar...@wam.umd.edu writes:
DES tells me he has a new version (0.10) which mmap()s. It supposedly
cuts the run time down significantly, I do not have the numbers in front
of me. Unfortunetly he has not posted this version yet so I cannot
download it and run it myself.
It's in
John-Mark Gurney gurne...@efn.org writes:
it was VERY simple to do... and attached is the patch... this uses the
option REG_STARTEND to do what the copy was trying to do... all of the
code to use REG_STARTEND was already there, it just needed to be enabled..
Funnily, I experience a
Dag-Erling Smorgrav d...@flood.ping.uio.no writes:
John-Mark Gurney gurne...@efn.org writes:
it was VERY simple to do... and attached is the patch... this uses the
option REG_STARTEND to do what the copy was trying to do... all of the
code to use REG_STARTEND was already there, it just
John-Mark Gurney wrote:
ok, I just made a patch to eliminate the copy that was happening in
procfile, and it sped up a grep of a 5meg termcap from about 2.9sec
down to .6 seconds... this includes time spent profiling the program..
GNU grep w/o profiling only takes .15sec so we ARE getting
Tim Vanderhoek wrote:
I'm sorry. I've read your message and have decided that you're wrong.
Not that you did bother to counter the points I made. You only
comment on the one thing I said was probably insignificant. Are you
taking your clues from me? :-)
Outside of the regexp library,
Dag-Erling Smorgrav wrote:
To be precise, I experience a 30% decrease in system time and a 100%
increase in user time when I use RE_STARTEND and eliminate the
malloc() / memcpy() calls in procfile().
Could you please test my patch that removes malloc() but bot
memcpy()? Here it is again,
Daniel C. Sobral d...@newsguy.com writes:
Dag-Erling Smorgrav wrote:
To be precise, I experience a 30% decrease in system time and a 100%
increase in user time when I use RE_STARTEND and eliminate the
malloc() / memcpy() calls in procfile().
Could you please test my patch that removes
Daniel C. Sobral d...@newsguy.com writes:
Could you please test my patch that removes malloc() but bot
memcpy()? Here it is again, though against an old version:
Bingo. REG_STARTEND is significantly more expensive than memcpy().
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To
Daniel C. Sobral scribbled this message on Jul 30:
Dag-Erling Smorgrav wrote:
To be precise, I experience a 30% decrease in system time and a 100%
increase in user time when I use RE_STARTEND and eliminate the
malloc() / memcpy() calls in procfile().
Could you please test my patch
On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote:
I said that I did not care whether the thing is inside or outside
the regexp library.
Yes, although I think at this point it's obvious we're coming at this
discussion from fairly different perspectives. By the time you
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
it was VERY simple to do... and attached is the patch... this uses the
option REG_STARTEND to do what the copy was trying to do... all of the
code to use REG_STARTEND was already there, it just needed to be enabled..
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
Funnily, I experience a near-doubling of running time with similar
patches.
Incidentally, it seems that it's not possible to assume that our
regex library is even anywhere in the same league as the GNU regex
library.
b$
On Thu, Jul 29, 1999 at 09:16:53PM +0900, Daniel C. Sobral wrote:
Sorry, but a simplistic analysis like that just won't cut for grep.
The algorithmic complexity is highly relevant here. Try this:
Algorithmic complexity!?!
Yup.
I'm sorry. I've read your message and have decided
On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
fgetln() does a complete copy of the line buffer whenever an
excessively long line is found. On this point, it's hard to do better
without using mmap(), but mmap() has its own disadvantages. My last
suggestion to James was to assume a worst case
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
warning type="Anything said here wrong is my fault, not DES's"
DES tells me he has a new version (0.10) which mmap()s. It supposedly
cuts the run time down significantly, I do not have the numbers in front
of me.
I do. Still
:of me. Unfortunetly he has not posted this version yet so I cannot
:download it and run it myself. He also says that if mmap fails, he drops
:back to stdio. This should only happen in the NFS case, the 2G case,
:etc.
It should only be the 2G case or the pipe case. mmap() works just
James Howard scribbled this message on Jul 29:
On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
fgetln() does a complete copy of the line buffer whenever an
excessively long line is found. On this point, it's hard to do better
without using mmap(), but mmap() has its own disadvantages. My
Tim Vanderhoek wrote:
On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote:
Sorry, but a simplistic analysis like that just won't cut for grep.
The algorithmic complexity is highly relevant here. Try this:
Algorithmic complexity!?!
Yup.
It's a freaking grep application.
On Thu, Jul 29, 1999 at 09:16:53PM +0900, Daniel C. Sobral wrote:
Sorry, but a simplistic analysis like that just won't cut for grep.
The algorithmic complexity is highly relevant here. Try this:
Algorithmic complexity!?!
Yup.
I'm sorry. I've read your message and have decided
On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
fgetln() does a complete copy of the line buffer whenever an
excessively long line is found. On this point, it's hard to do better
without using mmap(), but mmap() has its own disadvantages. My last
suggestion to James was to assume a worst case
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
warning type=Anything said here wrong is my fault, not DES's
DES tells me he has a new version (0.10) which mmap()s. It supposedly
cuts the run time down significantly, I do not have the numbers in front
of me.
I do. Still
:of me. Unfortunetly he has not posted this version yet so I cannot
:download it and run it myself. He also says that if mmap fails, he drops
:back to stdio. This should only happen in the NFS case, the 2G case,
:etc.
It should only be the 2G case or the pipe case. mmap() works just
James Howard scribbled this message on Jul 29:
On Thu, 29 Jul 1999, Tim Vanderhoek wrote:
fgetln() does a complete copy of the line buffer whenever an
excessively long line is found. On this point, it's hard to do better
without using mmap(), but mmap() has its own disadvantages. My
Tim Vanderhoek scribbled this message on Jul 29:
On Thu, Jul 29, 1999 at 07:05:57PM -0400, James Howard wrote:
warning type=Anything said here wrong is my fault, not DES's
DES tells me he has a new version (0.10) which mmap()s. It supposedly
cuts the run time down significantly, I do
Sheldon Hearn [EMAIL PROTECTED] writes:
In this case, the implementation we'll be introducing will introduce a
performance loss, not a gain.
Can you document that?
As far as stability goes, there's a loss
involved _if_ passing the GNU grep regression tests is
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote:
There seems to be at least one dependency on GNU grep in
/ports/Mk/bsd.port.mk where the -F argument is used.
-F is implemented.
I saw that, but had assumed the semantics were different. I should
have read the read
In message [EMAIL PROTECTED] "David O'Brien" writes:
: Before importing, it must display a version number of 1.0 (or drop the
: version number). This is not Linux where everything is version 0.xy.
For a long time the new boot loader was in the tree with a version
0.xx...
Warner
To
I expect that there is a very good reason why this shouldn't be done,
but could it be possible to implement two different algorithms/code
dependant on the size of the file being grepped?
Mark Dickey
[EMAIL PROTECTED]
Daniel C. Sobral wrote:
James Howard wrote:
Due to the discussion of
Doug [EMAIL PROTECTED] wrote:
The more complete the feature set, the better
off we are for my money.
Someone offering money? Quick, who's got the donations hat... :-)
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote:
Sorry, but a simplistic analysis like that just won't cut for grep.
The algorithmic complexity is highly relevant here. Try this:
Algorithmic complexity!?!
It's a freaking grep application. There is no freaking algorithmic
Brian F. Feldman gr...@freebsd.org writes:
That's true. I'd like to see the replacement grep do mmaping of the
input files if it doesn't already, as that would speed it up.
Shouldn't be too hard to implement, the way file operations are
abstracted. Patches? :)
DES
--
Dag-Erling Smorgrav -
Sheldon Hearn sheld...@uunet.co.za writes:
In this case, the implementation we'll be introducing will introduce a
performance loss, not a gain.
Can you document that?
As far as stability goes, there's a loss
involved _if_ passing the GNU grep regression tests is
Tim Vanderhoek vand...@ecf.utoronto.ca writes:
Have you run your systems with J-grep as a replacement for GNU grep
for a while (making sure nothing breaks)?
Yes.
There seems to be at least one dependency on GNU grep in
/ports/Mk/bsd.port.mk where the -F argument is used.
-F is implemented.
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote:
There seems to be at least one dependency on GNU grep in
/ports/Mk/bsd.port.mk where the -F argument is used.
-F is implemented.
I saw that, but had assumed the semantics were different. I should
have read the read the
In message 19990727214451.a66...@dragon.nuxi.com David O'Brien writes:
: Before importing, it must display a version number of 1.0 (or drop the
: version number). This is not Linux where everything is version 0.xy.
For a long time the new boot loader was in the tree with a version
0.xx...
James Howard wrote:
Due to the discussion of speed, I have been looking at it and it is really
slow. Even slower than I thought and I was thinking it was pretty slow.
So using gprof, I have discovered that it seems to spend a whole mess of
time in grep_malloc() and free(). So I pulled
I expect that there is a very good reason why this shouldn't be done,
but could it be possible to implement two different algorithms/code
dependant on the size of the file being grepped?
Mark Dickey
m...@bestweb.net
Daniel C. Sobral wrote:
James Howard wrote:
Due to the discussion of speed,
Doug d...@gorean.org wrote:
The more complete the feature set, the better
off we are for my money.
Someone offering money? Quick, who's got the donations hat... :-)
Peter
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote:
Sorry, but a simplistic analysis like that just won't cut for grep.
The algorithmic complexity is highly relevant here. Try this:
Algorithmic complexity!?!
It's a freaking grep application. There is no freaking algorithmic
Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the binary code.
What's more, the code is
On 27 Jul 1999 13:37:35 +0200, Dag-Erling Smorgrav wrote:
URL:http://www.freebsd.org/~des/software/grep-0.7.tar.gz
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
When I committed the port
Sheldon Hearn [EMAIL PROTECTED] writes:
Version 0.3 broke port-building badly. Does version 0.7 make it through
a build of a whole stack of ports?
Yes.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the
It seems Dag-Erling Smorgrav wrote:
Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the
On Tue, 27 Jul 1999, Soren Schmidt wrote:
It seems Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
Go for it, the more GNU stuff we nuke the better :)
-Søren
Geez, why don't
On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
Have you run your systems with J-grep as a replacement for GNU grep
for a while (making sure
On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote:
Getting rid of as much as possible, gradually, is a Very Good Thing;
this is how we get stability and performance improvements.
Only if the replacements are as stable and robust as their predecessors.
In this case, the
On Tue, 27 Jul 1999, Nickolay N. Dudorov wrote:
After making it on the CURRENT system I can only
see:
grep: filename: Undefined error: 0
for every filename.
Every file?
This caused by very "unusual" return values for
'grep_open' (and other '..._open') function
On Tue, Jul 27, 1999 at 08:23:44AM -0400, Tim Vanderhoek wrote:
How's it compare in speed? [I'd test it myself, but see my private
email...]
Okay, following-up on myself, and indirectly Sheldon,
It does seem a little too slow. I'm not sure that this is because it
doesn't use mmap.
On Tue, 27 Jul 1999 23:18:14 +0900, "Daniel C. Sobral" wrote:
I'm talking about cpdup, which can be found in
http://www.backplane.com/FreeBSD/. Someone posted a port at the
time, but I don't know if anyone ever committed the port.
I'll commit a port in the next few days.
Ciao,
Sheldon.
At 9:29 AM -0400 7/27/99, Tim Vanderhoek wrote:
On a file with 10+ lines, the speed difference is rather
restrictive. [...] Only about 10% of the time is spend in
procline(). There seems to be a lot of unnecessary strncpy()
that could be _easily_ avoided if free() on util.c:130 was
Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the binary code.
I move that we
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
On Tue, 27 Jul 1999, Soren Schmidt wrote:
It seems Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
Go for it, the more GNU
On 27 Jul 1999, Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
First, I'm all for this idea, and applaud you and Jamie for taking
it on. I do have a few questions. Does POSIX say
On Tue, 27 Jul 1999, Doug wrote:
First, I'm all for this idea, and applaud you and Jamie for taking
it on. I do have a few questions. Does POSIX say anything about grep, and
if so, is this version compliant? Also, I'd like to put in another vote
for full GNU grep feature compliance,
On Tue, 27 Jul 1999, Jamie Howard wrote:
I do not have a copy of POSIX, but I do have Unix98 which is a superset of
POSIX. Right now, excluding bugs, it is Unix 98 and therefore POSIX
compliant
Good news, thanks for addressing this concern.
except for -e. -e should permit
On Tue, 27 Jul 1999, Doug wrote:
Ah, well, if the world were limited to just what I could imagine,
how boring would that be? The more complete the feature set, the better
off we are for my money.
You misinterpretted, I didn't know you could do that therefore I didn't
implement that. I
On 27 Jul 1999, Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
Normally I don't post "me too" messages. I'll make an exception.
Me too.
--
- bill fumerola - [EMAIL PROTECTED] - BF1560
On Tue, 27 Jul 1999, James Howard wrote:
On Tue, 27 Jul 1999, Doug wrote:
Ah, well, if the world were limited to just what I could imagine,
how boring would that be? The more complete the feature set, the better
off we are for my money.
You misinterpretted, I didn't know you
$ uname -a
$ grep foo NONEXIST
Segmentation fault (core dumped)
$ gdb /usr/bin/grep grep.core
...
(no debugging symbols found)...
Core was generated by `grep'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done.
Jamie Howard (howar...@wam.umd.edu), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the binary code.
What's more, the code is
On 27 Jul 1999 13:37:35 +0200, Dag-Erling Smorgrav wrote:
URL:http://www.freebsd.org/~des/software/grep-0.7.tar.gz
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
When I committed the port (textproc/freegrep),
Sheldon Hearn sheld...@uunet.co.za writes:
Version 0.3 broke port-building badly. Does version 0.7 make it through
a build of a whole stack of ports?
Yes.
DES
--
Dag-Erling Smorgrav - d...@yes.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body
On 27 Jul 1999 13:48:21 +0200, Dag-Erling Smorgrav wrote:
Version 0.3 broke port-building badly. Does version 0.7 make it through
a build of a whole stack of ports?
Yes.
Excellent. I'll nuke the port once you've merged the new grep to STABLE.
:-)
Later,
Sheldon.
To Unsubscribe: send
It seems Dag-Erling Smorgrav wrote:
Jamie Howard (howar...@wam.umd.edu), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth
On Tue, 27 Jul 1999, Soren Schmidt wrote:
It seems Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
Go for it, the more GNU stuff we nuke the better :)
-S?ren
Geez, why don't
On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
Have you run your systems with J-grep as a replacement for GNU grep
for a while (making sure
On Tue, 27 Jul 1999 08:19:38 -0400, Brian F. Feldman wrote:
Getting rid of as much as possible, gradually, is a Very Good Thing;
this is how we get stability and performance improvements.
Only if the replacements are as stable and robust as their predecessors.
In this case, the
In xzpd7xeb9xc@des.follo.net Dag-Erling Smorgrav d...@yes.no wrote:
Jamie Howard (howar...@wam.umd.edu), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one
On Tue, 27 Jul 1999, Sheldon Hearn wrote:
In this case, I'm all for the change, since I don't use grep for serious
regex work and the readability gain outweighs any loss of performance.
you probably feel the same way. Out opinions are those of developers,
though. It's always worth remembering
On Tue, 27 Jul 1999 07:49:22 EST, David Scheidt wrote:
Does any have numbers about how much slower the new grep is?
Just by the way, if the latest version somehow uses mmap without my
having noticed, then I've ontroduced a red herring. ;-)
Version 0.3 certainly didn't use mmap. As I
On Tue, 27 Jul 1999, Sheldon Hearn wrote:
On Tue, 27 Jul 1999 08:19:38 -0400, Brian F. Feldman wrote:
Getting rid of as much as possible, gradually, is a Very Good Thing;
this is how we get stability and performance improvements.
Only if the replacements are as stable and robust as
On Tue, 27 Jul 1999, Nickolay N. Dudorov wrote:
After making it on the CURRENT system I can only
see:
grep: filename: Undefined error: 0
for every filename.
Every file?
This caused by very unusual return values for
'grep_open' (and other '..._open') function which
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
That's true. I'd like to see the replacement grep do mmaping of the
input files if it doesn't already, as that would speed it up. Anyway,
It does not use mmap right now. And this causes a significant perforamce
hit on larger files. An older
On Tue, Jul 27, 1999 at 08:23:44AM -0400, Tim Vanderhoek wrote:
How's it compare in speed? [I'd test it myself, but see my private
email...]
Okay, following-up on myself, and indirectly Sheldon,
It does seem a little too slow. I'm not sure that this is because it
doesn't use mmap.
Brian F. Feldman wrote:
Geez, why don't we just write our own compiler and linker, assembler,
and everything? Let's get every last bit of GNU out of our system, for
no reason! This kind of NIH is not necessary, and only hurts us by
misdirecting our energies.
/joking
Seriously, I'd love
Dag-Erling Smorgrav wrote:
Jamie Howard (howar...@wam.umd.edu), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the
Brian F. Feldman wrote:
That reminds me. I'd like to see something like stat(1) go into the source
tree, but only if it were freely licensed, not GPL-infected. I could do
it in a day, I suppose, if it were worth it. Worth it is here defined as
would be accepted to go in usr.bin.
May I
On Tue, 27 Jul 1999 23:18:14 +0900, Daniel C. Sobral wrote:
I'm talking about cpdup, which can be found in
http://www.backplane.com/FreeBSD/. Someone posted a port at the
time, but I don't know if anyone ever committed the port.
I'll commit a port in the next few days.
Ciao,
Sheldon.
To
At 9:29 AM -0400 7/27/99, Tim Vanderhoek wrote:
On a file with 10+ lines, the speed difference is rather
restrictive. [...] Only about 10% of the time is spend in
procline(). There seems to be a lot of unnecessary strncpy()
that could be _easily_ avoided if free() on util.c:130 was
Jamie Howard (howar...@wam.umd.edu), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the binary code.
I move that we
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
On Tue, 27 Jul 1999, Soren Schmidt wrote:
It seems Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
Go for it, the more GNU
On 27 Jul 1999, Dag-Erling Smorgrav wrote:
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
First, I'm all for this idea, and applaud you and Jamie for taking
it on. I do have a few questions. Does POSIX say
On 1999-07-27 13:37:35 +0200, Dag-Erling Smorgrav wrote:
Jamie Howard (howar...@wam.umd.edu), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source
1 - 100 of 110 matches
Mail list logo
