Anyway 9 seconds are not that much..

See how it works out in the real thing.

especially if I start with your algo...

index isn't my algo, just a poor, pure perl substitute for it.

If you look closely at the inline C version, longCmp() is not your average brute force string search. It uses several short circuits to avoid unnecessary comparisons.

For example, it checks the last byte in the haystack up front.

• First, there is no point in comparing all 300 bytes if the last bytes don't match.

  When longCmp() encounter this scenario:

  haystack:....0ACGTACGTACGT0....
  needle  :     ACGTACGc
  [download]

  The fact that the last bytes to be matched are different means it doesn't have to compare all the intermediates to discover than and can move forward to the next position.

• Second, if the last byte that would be compared is 0, then not only is there no point in comparing these two, but we can skip ahead to the start of the next string in the haystack.

  That is, when longCmp() tries this comparison:

  haystack:....0ACGTACGTACGT0....
  needle  :          AACCGGTT
  [download]

  It sees that the last byte that would be compared is a null, and not only skips that comparison, but skips ahead to the start of the next string:

  haystack:....0ACGTACGTACGT0....
  needle  :                  AACCGGTT
  [download]

It isn't possible to code this kind of logic in perl efficiently, hence the inline C solution. My pure perl version was simply a poor substitute until the OP can sort out his Inline::C install.