bug#15808: 24.3; thing-at-point slow for url and email

bug#15808: 24.3; thing-at-point slow for url and email

[Leo Liu]

GNU Emacs 24.3.1 (i386-apple-darwin13.0.0, Carbon Version 1.6.0 AppKit
1265) of 2013-10-27 on localhost

While using M-w in simple.el using easy-kill I noticed some delays which
are due to slow (thing-at-point 'url) and (thing-at-point 'email).

If I narrow the buffer, they become instant. However slowness doesn't
appear to be proportional to buffer-size, I tried the org.el file and
they were instant there.

For example

1. goto function next-error-buffer-p in simple.el
2. eval (benchmark-run 10 (thing-at-point 'email))
3. eval (benchmark-run 10 (thing-at-point 'url))

email: (4.415538 0 0.0)
url: (6.74361 0 0.0)

What is choking the regexp engine?

Leo

bug#15808: 24.3; thing-at-point slow for url and email

[Andreas Röhler]

Am 05.11.2013 03:52, schrieb Leo Liu:
> GNU Emacs 24.3.1 (i386-apple-darwin13.0.0, Carbon Version 1.6.0 AppKit
> 1265) of 2013-10-27 on localhost
>
> While using M-w in simple.el using easy-kill I noticed some delays which
> are due to slow (thing-at-point 'url) and (thing-at-point 'email).
>
> If I narrow the buffer, they become instant. However slowness doesn't
> appear to be proportional to buffer-size, I tried the org.el file and
> they were instant there.
>
> For example
>
> 1. goto function next-error-buffer-p in simple.el
> 2. eval (benchmark-run 10 (thing-at-point 'email))
> 3. eval (benchmark-run 10 (thing-at-point 'url))
>
> email: (4.415538 0 0.0)
> url: (6.74361 0 0.0)
>
> What is choking the regexp engine?
>
> Leo
>
>
>
>

WRT the url-matter:

There is no need to delegate proceeding upon a separate function dealing with URL, as the basic scheme already accepts a function.
Just put the appropriate one there.

Also thing-at-point--bounds-of-well-formed-url seems doing a kind of double-check, which seems good as analyze-tool when bug-reporting, but nothing to fire up all the time.

Etc.

HTH,

Andreas

bug#15808: 24.3; thing-at-point slow for url and email

[Stefan Monnier]

> What is choking the regexp engine?

Try it with M-x profiler-start RET RET ... M-x profiler-report RET.


        Stefan

bug#15808: 24.3; thing-at-point slow for url and email

[Leo Liu]

On 2013-11-06 00:32 +0800, Stefan Monnier wrote:
> Try it with M-x profiler-start RET RET ... M-x profiler-report RET.
>
>
>         Stefan

I got the following which doesn't seem useful. Am I wrong? Thanks - Leo

CPU:

+ if                                                              144  35%
+ let                                                             141  34%
+ call-interactively                                               83  20%
  Automatic GC                                                     20   4%
  redisplay_internal (C function)                                  11   2%
+ read-from-minibuffer                                              4   0%
+ easy-kill                                                         1   0%
+ list                                                              1   0%

MEM:

+ call-interactively                                        6,531,039  99%
  redisplay_internal (C function)                              14,256   0%
+ let                                                              74   0%

bug#15808: 24.3; thing-at-point slow for url and email

[Stefan Monnier]

>> Try it with M-x profiler-start RET RET ... M-x profiler-report RET.
> I got the following which doesn't seem useful. Am I wrong? Thanks - Leo

You need to `C-u RET' on the lines with the + to see more details.

> + if                                                              144  35%

The count is too small: this is a sample-based profiler, so you need
a long enough runtime to get meaningful results (otherwise, the various
stack fragments collected can't be pieced together to get the whole tree).

Also, it seems some of the code is interpreted.  If the result is still
hard to interpret, you might want to try and byte-compile that code.

> + call-interactively                                        6,531,039  99%

That looks much more promising.  What does C-u RET show?


        Stefan

bug#15808: 24.3; thing-at-point slow for url and email

[Leo Liu]

On 2013-11-06 10:18 +0800, Stefan Monnier wrote:
> The count is too small: this is a sample-based profiler, so you need
> a long enough runtime to get meaningful results (otherwise, the various
> stack fragments collected can't be pieced together to get the whole tree).
>
> Also, it seems some of the code is interpreted.  If the result is still
> hard to interpret, you might want to try and byte-compile that code.

I tried the thingatpt.el and the URL case is not slow there but email
is. Profiler says most time is spent in thing-at-point-looking-at. I
propose the following fix? Comments?

=== modified file 'lisp/thingatpt.el'
--- lisp/thingatpt.el	2013-08-10 15:17:29 +0000
+++ lisp/thingatpt.el	2013-11-06 03:32:52 +0000
@@ -476,7 +476,7 @@
 ;; matches that straddle the start position so we search forwards once
 ;; and then back repeatedly and then back up a char at a time.
 
-(defun thing-at-point-looking-at (regexp)
+(defun thing-at-point-looking-at (regexp &optional limit)
   "Return non-nil if point is in or just after a match for REGEXP.
 Set the match data from the earliest such match ending at or after
 point."
@@ -487,7 +487,7 @@
 	   (setq match (point)))
       ;; Search back repeatedly from end of next match.
       ;; This may fail if next match ends before this match does.
-      (re-search-forward regexp nil 'limit)
+      (re-search-forward regexp limit 'limit)
       (while (and (re-search-backward regexp nil t)
 		  (or (> (match-beginning 0) old-point)
 		      (and (looking-at regexp)	; Extend match-end past search start
@@ -518,7 +518,8 @@
 
 (put 'email 'bounds-of-thing-at-point
      (lambda ()
-       (let ((thing (thing-at-point-looking-at thing-at-point-email-regexp)))
+       (let ((thing (thing-at-point-looking-at thing-at-point-email-regexp
+					       (+ (point) 500))))
          (if thing
              (let ((beginning (match-beginning 0))
                    (end (match-end 0)))

bug#15808: 24.3; thing-at-point slow for url and email

[Leo Liu]

Revised patch:

=== modified file 'lisp/thingatpt.el'
--- lisp/thingatpt.el	2013-08-10 15:17:29 +0000
+++ lisp/thingatpt.el	2013-11-06 03:43:24 +0000
@@ -476,19 +476,22 @@
 ;; matches that straddle the start position so we search forwards once
 ;; and then back repeatedly and then back up a char at a time.
 
-(defun thing-at-point-looking-at (regexp)
+(defun thing-at-point-looking-at (regexp &optional distance)
   "Return non-nil if point is in or just after a match for REGEXP.
 Set the match data from the earliest such match ending at or after
 point."
   (save-excursion
-    (let ((old-point (point)) match)
+    (let ((old-point (point))
+	  (forward-bound (and distance (+ (point) distance)))
+	  (backward-bound (and distance (- (point) distance)))
+	  match)
       (and (looking-at regexp)
 	   (>= (match-end 0) old-point)
 	   (setq match (point)))
       ;; Search back repeatedly from end of next match.
       ;; This may fail if next match ends before this match does.
-      (re-search-forward regexp nil 'limit)
-      (while (and (re-search-backward regexp nil t)
+      (re-search-forward regexp forward-bound 'limit)
+      (while (and (re-search-backward regexp backward-bound t)
 		  (or (> (match-beginning 0) old-point)
 		      (and (looking-at regexp)	; Extend match-end past search start
 			   (>= (match-end 0) old-point)
@@ -518,7 +521,8 @@
 
 (put 'email 'bounds-of-thing-at-point
      (lambda ()
-       (let ((thing (thing-at-point-looking-at thing-at-point-email-regexp)))
+       (let ((thing (thing-at-point-looking-at
+		     thing-at-point-email-regexp 500)))
          (if thing
              (let ((beginning (match-beginning 0))
                    (end (match-end 0)))

bug#15808: 24.3; thing-at-point slow for url and email

[Stefan Monnier]

> Revised patch:

Looks OK, thanks.  Maybe other calls to thing-at-point-looking-at could
benefit as well.


        Stefan

bug#15808: 24.3; thing-at-point slow for url and email

[Leo Liu]

Fixed in 24.4.

On 2013-11-06 14:55 +0800, Stefan Monnier wrote:
> Looks OK, thanks.  Maybe other calls to thing-at-point-looking-at could
> benefit as well.

Both url and email used to use thing-at-point-looking-at. But the URL
case has been re-written. So there is only one use of
thing-at-point-looking-at i.e. it's all covered.

Leo