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 <file://(%3F:.//%7C/n//)*?goto>")
 (let ((here (point)))
   (prog1
       (re-search-forward
"\\=\\(?:.\\|\n\\)*?goto<file://=//(?:.//%7C/n//)*?goto>"
100 t)
     (goto-char here))))
      )))