On 7/17/08, Miles Bader <miles.bader@necel.com> wrote:
"Lennart Borgman" <lennart.borgman@gmail.com> writes:

>> > Yes, that is one possibility. But then perhaps I would assume that
>> > re-search-forward better might optimize that search since it can
>> > (in theory) cut off the searching at BOUND. In the case I am
>> > looking at performance is important.
>>
>> Why don't you time it?
>
> Because I thought someone here knew more about the performance differences
> (if any). I am also a bit surprised that looking-at does not have a BOUND
> parameter and hoped to get some comments on that.

Offhand it doesn't fit looking-at's interface particulary well -- while
you can come up with semantics for such a parameter, they're not
something obviously useful as is the case for searches.  Also, for
typical uses of looking-at, the performance difference isn't a factor.

Anyway, it seems a lot better to get actual data than
pontificate... premature optimization is the root of all evil,
after all... :-)
 
It looks like the performance is pretty equal. Here is my test code:
 

(benchmark-elapse
  (goto-char (point-min))
  (let ((times 10000))
    (while (> times 0)
      (setq times (1- times))

      (if nil
   (looking-at "\\(?:.\\|\n\\)*?goto")
 (let ((here (point)))
   (prog1
       (re-search-forward "\\=\\(?:.\\|\n\\)*?goto" 100 t)
     (goto-char here))))
      )))