Live data from Hacker News

Why GNU grep is fast (2010)

lists.freebsd.org

51–60 of 133 posts

Re: Why GNU grep is fast (2010)

#51
post #45

The inverse is this...what is modern software doing that makes them so slow?

Figuratively speaking, a lot of modern software is busy peeling layers of various onions, going to places to check if it needs to go there, and writing and organizing detailed reports of what it's doing, every step along the way. In other words, bureaucracy and logistics.

Re: Why GNU grep is fast (2010)

#52
That is similar to how I explain to some students how have a fast database system: The key to a fast query is one that do little, and the way to make it do little is have the data exactly as how is needed.

Re: Why GNU grep is fast (2010)

#53

That's also a Forth way of looking at optimization. Also reminds me of Kent Beck's quip when he was asked to optimize Chrysler's C3 system. He asked for validated sets of input and output. The programmers on site said the the system wasn't producing correct results yet. His response: In that case, I can make this real fast!

[deleted]

Re: Why GNU grep is fast (2010)

#54
post #36

Earlier quoted context omitted.

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.

In the past, there were semi-automated accounts that did this, but they made more people upset than happy. I would also prefer to see this happen on every story.

hey hey hey, if you want hacker news to stay fast you should't make it do too much!

Re: Why GNU grep is fast (2010)

#57
post #53

That's also a Forth way of looking at optimization. Also reminds me of Kent Beck's quip when he was asked to optimize Chrysler's C3 system. He asked for validated sets of input and output. The programmers on site said the the system wasn't producing correct results yet. His response: In that case, I can make this real fast!

[deleted]

I think Kent was being sarcastic - his point is that it's rather pointless to optimize until the system is producing correct results. He's also famous for the "Make it work, make it right, make it fast" quote.

Re: Why GNU grep is fast (2010)

#58
post #46
post #37

Earlier quoted context omitted.

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 tim…

I wholly agree that it's worth investing in finding the best solution. However, in my experience I found that having concrete code to work with is invaluable . The magic bullet for me is to slap something concrete together, then aggressively refactor / cut the crap out of it. In some sense, building software is like sculpture. You've got this amorphous block of half baked ideas, and you need to turn it somehow into a…

I call that "sketching in code." I've gotten in some trouble in interviews for "starting to write code right away," so it's a habit I'm having to fight at the moment, but I find having something in code (that I'm fully willing to throw away) really helps.

It's like Fred Brooks said:

    ...plan to throw one away; you will, anyhow.

Re: Why GNU grep is fast (2010)

#59

Earlier quoted context omitted.

In the past, there were semi-automated accounts that did this, but they made more people upset than happy. I would also prefer to see this happen on every story.

hey hey hey, if you want hacker news to stay fast you should't make it do too much!

The systems I wrote were independent of HN and didn't slow it down. I got significant grief for them and pulled them.

Standard "wisdom" for start-ups includes "If you're not embarrassed by your first product then you didn't launch early enough," and "Try the minimal viable product before investing too much time." I both launched early, and made sure the "product" was absolutely minimal. It got slated by the people it was trying to help, so I didn't bother refining it.

The experience was educational and instructive.

(minor edit to remove some inappropriate snark - apologies)

Re: Why GNU grep is fast (2010)

#60
I'm actually more familiar with the KMP algorithm than BM. So I looked it up to see what the difference was:

The classic Boyer-Moore algorithm suffers from the phenomenon that it tends not to work so efficiently on small alphabets like DNA.

The skip distance tends to stop growing with the pattern length because substrings re-occur frequently.

By remembering more of what has already been matched, one can get larger skips through the text.

One can even arrange 'perfect memory' and thus look at each character at most once, whereas the Boyer-Moore algorithm, while linear, may inspect a character from the text multiple times.

1: http://stackoverflow.com/questions/12656160/what-are-the-mai...

Post reply on HN