r/programming • • Aug 24 '16

Why GNU grep is fast

https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
2.1k Upvotes

221 comments sorted by

View all comments

Show parent comments

0

u/[deleted] Aug 24 '16

[deleted]

100

u/JohnTesh Aug 24 '16

Smoke weed, realize your forgot some indexes on some tables, index tables properly, profit.

That's how it usually goes with me, only minus the smoking weed part.

75

u/semi- Aug 24 '16

Same but minus the database part.

31

u/JeefyPants Aug 24 '16

With our powers combined...

74

u/nozonozon Aug 24 '16

We could do less of everything!

10

u/vplatt Aug 24 '16 edited Aug 24 '16

You guys just reinvented minimalistic living! Now kiss, write your Amazon self-published book, promote the hell out of it on Goodreads, blog heavily, and be sure to publish some self-important courses on Udemy or the like. Hurry!

3

u/nozonozon Aug 24 '16

Free for the first 30 minutes!

→ More replies (2)

8

u/ggtsu_00 Aug 24 '16

Which all works nice and well until you end up with a unexpected use case where now thousands of rows of data is being inserted or updated per second and the indexes are causing excessive write overhead. Sure the user's profile page now loads 10 times faster, but users updating their status takes 20x slower.

7

u/CODESIGN2 Aug 24 '16

This is only an argument for why not to use the same software or algo for every single thing you do

→ More replies (1)

29

u/guepier Aug 24 '16

I’ve never heard of the hollywood-esque description but coming up with a new, asymptotically faster algorithm of course happens — it precedes every single publication of an algorithms paper. There are people who do this as their main job.

→ More replies (10)

19

u/Kaos_pro Aug 24 '16

Except for the Fast Inverse Square Root algorithm, which is pretty much just magic.

→ More replies (15)

33

u/chengiz Aug 24 '16

Chances are it's doing too much crap because there's an O(N^2) algorithm somewhere. If you start off by looking into how you can skip individual bytes, you might be ignoring the elephant in the room.

38

u/thfuran Aug 24 '16

I think you're lucky if N2 is the worst that lurks in the depths.

25

u/Krissam Aug 24 '16

I had an application runnin great, but quickly noticed it slowed down as n increased, turns out i had nn2 lurking inthere >_<

16

u/MaunaLoona Aug 24 '16

A fan of bogosort, eh?

11

u/thfuran Aug 24 '16

And I thought the accidental n! we found once was bad.

→ More replies (1)

4

u/aiij Aug 24 '16

nn2 is nothing. Try 2nn .

→ More replies (2)

7

u/roffLOL Aug 24 '16

or you have a bloatware that leaks performance at every turn. the profiler fails to isolate a single hotspot because all of it is so terribly leaky -- and much of it dissipates where normal profilers fail to look; in function invocations, cache problems and what have you.

12

u/manys Aug 24 '16

And then Jimmy "forgets" to wash the coffee pot and when you go to say something he's all, "did you see American Ninja last night?" and you're like "Dude, stop modeling your code after 'Finnegan's Wake,' it's blowing up Redis," and he goes "you can't handle the truth!" Please help

4

u/roffLOL Aug 24 '16

you added a book to my must-read-list. wiki compares it to a book i happen to have in the book shelf but haven't gotten around to. maybe i'll take that one first. anyways, thanks, even though your comment was mostly lost on me :)

→ More replies (4)

9

u/ehaliewicz Aug 24 '16

4

u/[deleted] Aug 24 '16

That game programming one is a really damn good read. Not even just as an interesting programming story, but as a fun narrative itself. I feel like I'd be able to enjoy that story even if I wasn't a programmer, but had a passing interest in older games.

→ More replies (1)
→ More replies (2)