The problem with grep is that it needs to have an entire line in memory. If that line is so large that it doesn't fit in memory, than grep bombs. The only way around this dilemma is to feed small chunks to grep. (which is really what grep should be doing itself, anyway, but it doesn't).
dd so that you can specify an offset to start at, and use
grep --mmap to avoid running out of memory on a line that is larger than the available RAM.
grep --mmap will prevent the system from choking, but may or may not prevent grep itself from choking. This would be a good thing for someone to test.
fold will allow you to insert a newline at regular intervals, this satisfies the criteria to split the input into manageable chunks.
dd if=bigfile skip=xxx | fold | grep -b -a string
-b gives you the byte offset which you will find useful to know where your text strings are located within the file.
I tested this on a 100GB logical volume on one of my KVM hypervisors, using the search string "Hard" and running vmstat in a separate window to monitor performance. The logical volume is basically formatted as a hard drive (partitions and filesystems) on which a guest Linux VM is installed. There wasn't any impact on system performance. It processed each gig in about 33 seconds (of course this will vary widely depending on your hardware).
You said you wanted quick performance. This should give you the quickest performance from using utilities in a shell script. The only way to get a quicker search would be to write a program in C that seeks to an offset, reads in a specified chunksize, feeds that chunk into a pattern matching algorithm, before moving on to the next chunk. Seems like this type of "improved grep" should already be in existence, but searching online I don't find one.