What is the difference between looking-at and an anchored search?

What is the difference between looking-at and an anchored search?

[Lennart Borgman (gmail)]

looking-at does not have a BOUND parameter, but re-search-forward have. 
This makes re-search-forward a bit more flexible.

I am looking at some code where I would have use for that flexibility, 
but I wonder if there is any drawback with replacing looking-at with 
re-search-forward (with an achored pattern).

Is there any? Performance?

Re: What is the difference between looking-at and an anchored search?

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> looking-at does not have a BOUND parameter, but re-search-forward
> have. This makes re-search-forward a bit more flexible.
>
> I am looking at some code where I would have use for that flexibility,
> but I wonder if there is any drawback with replacing looking-at with
> re-search-forward (with an achored pattern).
>
> Is there any? Performance?

If you want to reject matches that extend past some point, just do
something like:

   (and (looking-at REGEXP) (<= (match-end 0) BOUND))

-Miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: What is the difference between looking-at and an anchored search?

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

On 7/17/08, Miles Bader <miles.bader@necel.com> wrote:

> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> > looking-at does not have a BOUND parameter, but re-search-forward
> > have. This makes re-search-forward a bit more flexible.
> >
> > I am looking at some code where I would have use for that flexibility,
> > but I wonder if there is any drawback with replacing looking-at with
> > re-search-forward (with an achored pattern).
> >
> > Is there any? Performance?
>
> If you want to reject matches that extend past some point, just do
> something like:
>
>   (and (looking-at REGEXP) (<= (match-end 0) BOUND))


Thanks Miles,

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.

[-- Attachment #2: Type: text/html, Size: 1312 bytes --]

Re: What is the difference between looking-at and an anchored search?

[Johan Bockgård]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

>> If you want to reject matches that extend past some point, just do
>> something like:
>>
>>   (and (looking-at REGEXP) (<= (match-end 0) BOUND))
>
>
> Thanks Miles,
>
> 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.

You can try narrowing the buffer.

-- 
Johan Bockgård

Re: What is the difference between looking-at and an anchored search?

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> looking-at does not have a BOUND parameter, but re-search-forward
>> have. This makes re-search-forward a bit more flexible.
>>
>> I am looking at some code where I would have use for that flexibility,
>> but I wonder if there is any drawback with replacing looking-at with
>> re-search-forward (with an achored pattern).
>>
>> Is there any? Performance?
>
> If you want to reject matches that extend past some point, just do
> something like:
>
>    (and (looking-at REGEXP) (<= (match-end 0) BOUND))

That is not the same.

(with-temp-buffer (insert "abc")
  (goto-char 1)
  (list
    (re-search-forward ".*" 2)
    (progn (goto-char 1)
      (and (looking-at ".*") (<= (match-end 0) 2)))))

=> (2 nil)

-- 
David Kastrup

Re: What is the difference between looking-at and an anchored search?

[Miles Bader]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:
>> If you want to reject matches that extend past some point, just do
>> something like:
>>
>>   (and (looking-at REGEXP) (<= (match-end 0) BOUND))
>
> Thanks Miles,
>
> 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?

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: What is the difference between looking-at and an anchored search?

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On 7/17/08, Miles Bader <miles.bader@necel.com> wrote:
>
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
> >> If you want to reject matches that extend past some point, just do
> >> something like:
> >>
> >>   (and (looking-at REGEXP) (<= (match-end 0) BOUND))
> >
> > Thanks Miles,
> >
> > 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.

But otherwise it is of course a good suggestion to time it.

[-- Attachment #2: Type: text/html, Size: 1285 bytes --]

Re: What is the difference between looking-at and an anchored search?

[Miles Bader]

"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... :-)

-miles

-- 
Monday, n. In Christian countries, the day after the baseball game.

Re: What is the difference between looking-at and an anchored search?

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

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))))
      )))

[-- Attachment #2: Type: text/html, Size: 2241 bytes --]

Re: What is the difference between looking-at and an anchored search?

[Lennart Borgman (gmail)]

Johan Bockgård wrote:
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
> 
>>> If you want to reject matches that extend past some point, just do
>>> something like:
>>>
>>>   (and (looking-at REGEXP) (<= (match-end 0) BOUND))
>>
>> Thanks Miles,
>>
>> 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.
> 
> You can try narrowing the buffer.

Ah, thanks that is a good suggestion.

Eh, at least to my question, but I am beginning to realize that I have 
asked the wrong question. I wanted to modify the xmltok.el library that 
comes with nxml so that it could be used with mumamo in a better way 
than now. I want to jump over regions that are not parseable by 
nxml-mode. (I thought I had already done that, but forgot about xmltok.el.)

I will ask some questions about that in a separate thread.