You have reasons to be frustrated

[mobiphil]

While I feel enough pity about your disgusting comments like the one below, your burnouts you are reporting on your blog, but definitively your attitude will not attract people to help you! You must be very unhappy with yourself!

Quote from your reply on comment.
"I can only urge you to continue learning about computation and to think about problems from first principles."

Btw, it turns out that there are faster implementation than yours, and probably people spent less narcissistic and self-pity blog entries on the issues.

https://github.com/monochromegane/the_platinum_searcher

[mobiphil]

I made the suggestion below, but your reply was one of a psychopath!

hi, thanks for your work on ag! Really impressive tool. Would have four suggestions:
-> one hint for speedup: did you think/try asynchronous io? Under certain conditions usync io on several files can be much faster on one thread than sync io on multiple threads (http://www.kegel.com/c10k.html.... I tried to search for random regex in /usr which is on o very fast SSD on a 8 core AMD machine. The CPU usage is 300% which means less than half of computing power is used. Strange that even with hot cache, this does not strange. I assume that on slower disks lot of time would be spent on IO. If all threads are blocked on IO, which is very likely, nobody is working.
-> doing sthg. like ag "a._r._b.n." will do the fuzzy find. Suggestion: a flag (-y is not taken) that will automatically convert ag -y arbn to the above
-> implement a new mode, where you would internally cache the buffers, and doo interactive fuzzy find az FZF (https://github.com/junegunn/fz...

-> implement a server mode where you would cache the buffers and do like above but search for strings comming on a socket or pipe. This would be very powerful to implement plugins like FZF, but obviously you would do much more than FZF