I know all this, but it still feels like a magic when you run it against a fat log file and it's done in a couple of seconds, while awk and tail were previously struggling with it for like 15 minutes...
Why GNU grep is fast (2010)
31–40 of 133 posts
Re: Why GNU grep is fast (2010)
#32what is grep?
A text search utility in Unix. Name comes from a command in the text editor ed and stands for "global regular expression print".
Re: Why GNU grep is fast (2010)
#33what is grep?
Re: Why GNU grep is fast (2010)
#34This applies very well to optimization, too. There are only really two ways to optimize code: 1) make it do less 2) make it do more at a time. The first corresponds to using more efficient algorithms and data structures. The second is parallelism.
> The second is parallelism.
Or vectorization, or avoiding stalling, or filling all execution units, or...
Re: Why GNU grep is fast (2010)
#35Earlier quoted context omitted.
> "The fastest method to execute is an empty method." The fastest method to execute is an empty method that was never called. The fastest method to execute is an empty method that was never called and never written. The fastest method to execute is an empty method that was never called and never written and never planned.
This is why I say I'm at my most efficient when I just don't do any work at all.
Funny, but I think you finally went too far! Speed is one thing, and not executing a function sure can happen fast, but efficiency is productivity per unit time, and if there is no productivity, it can't be "most efficient". (Yes, I'm a pedant sometimes.)
Re: Why GNU grep is fast (2010)
#36In case you're interested to see what older HN contributors had to say about this, here are some of the previous submissions, all of which have significant discussion: https://news.ycombinator.com/item?id=1626305 , 1193 days ago, 115 comments https://news.ycombinator.com/item?id=2393587 , 972 days ago, 68 comments https://news.ycombinator.com/item?id=2860759 , 842 days ago, 43 comments ( ionelm also pointed out a pre…
It's great that you posted this, but it would be greater if HN was capable of doing it automatically since it is mostly trivial, but provides a lot of value.
Re: Why GNU grep is fast (2010)
#37This applies very well to optimization, too. There are only really two ways to optimize code: 1) make it do less 2) make it do more at a time. The first corresponds to using more efficient algorithms and data structures. The second is parallelism.
I've found that taking a considerable amount of time (days even) to determine the very best solution to a problem always results in less effort and less time spent coding overall. It's also no coincidence that the code becomes incredibly simple, more readable, more efficient, more flexible, easier to build on top of, and fewer issues down the road. Plus, in the end, depending on the magnitude of the project, less time is spent on overall development.
It is never a good idea to rush any large coding project. By rush, I mean just sit down and start churning out code just so you can have something tangible within a day or two. And by large, I mean anything requiring at least a few thousand LOC. Anything less can be okay to rush though; i.e., small projects where maintainability and scalability aren't as important; e.g., some MVP to test some market.
Re: Why GNU grep is fast (2010)
#38This is why Rails fails.
Re: Why GNU grep is fast (2010)
#39In case you're interested to see what older HN contributors had to say about this, here are some of the previous submissions, all of which have significant discussion: https://news.ycombinator.com/item?id=1626305 , 1193 days ago, 115 comments https://news.ycombinator.com/item?id=2393587 , 972 days ago, 68 comments https://news.ycombinator.com/item?id=2860759 , 842 days ago, 43 comments ( ionelm also pointed out a pre…
See also:
http://swtch.com/~rsc/regexp/regexp1.html
http://swtch.com/~rsc/regexp/regexp2.html
http://swtch.com/~rsc/regexp/regexp3.html
http://en.wikipedia.org/wiki/Thompson%27s_construction_algor...
I implemented a sort of micro-grep in the past using the Thompson's algorithm, it was a great exercise in practical applications of heavily-theoretical CS stuff, with recursive-descent parsing of the regular expression, then using Thompsons algorithm to create a NFA out of the parse tree, then a simulation of an NFA with a DFA using two stacks. I used the Dragon Book for reference on this, all pretty awesome stuff.