* bug#15808: 24.3; thing-at-point slow for url and email
@ 2013-11-05 2:52 Leo Liu
2013-11-05 8:41 ` Andreas Röhler
2013-11-05 16:32 ` Stefan Monnier
0 siblings, 2 replies; 9+ messages in thread
From: Leo Liu @ 2013-11-05 2:52 UTC (permalink / raw)
To: 15808
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15808: 24.3; thing-at-point slow for url and email
2013-11-05 2:52 bug#15808: 24.3; thing-at-point slow for url and email Leo Liu
@ 2013-11-05 8:41 ` Andreas Röhler
2013-11-05 16:32 ` Stefan Monnier
1 sibling, 0 replies; 9+ messages in thread
From: Andreas Röhler @ 2013-11-05 8:41 UTC (permalink / raw)
To: 15808
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15808: 24.3; thing-at-point slow for url and email
2013-11-05 2:52 bug#15808: 24.3; thing-at-point slow for url and email Leo Liu
2013-11-05 8:41 ` Andreas Röhler
@ 2013-11-05 16:32 ` Stefan Monnier
2013-11-06 0:59 ` Leo Liu
1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2013-11-05 16:32 UTC (permalink / raw)
To: Leo Liu; +Cc: 15808
> What is choking the regexp engine?
Try it with M-x profiler-start RET RET ... M-x profiler-report RET.
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#15808: 24.3; thing-at-point slow for url and email
2013-11-05 16:32 ` Stefan Monnier
@ 2013-11-06 0:59 ` Leo Liu
2013-11-06 2:18 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Leo Liu @ 2013-11-06 0:59 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 15808
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%
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#15808: 24.3; thing-at-point slow for url and email
2013-11-06 0:59 ` Leo Liu
@ 2013-11-06 2:18 ` Stefan Monnier
2013-11-06 3:35 ` Leo Liu
2013-11-06 3:45 ` Leo Liu
0 siblings, 2 replies; 9+ messages in thread
From: Stefan Monnier @ 2013-11-06 2:18 UTC (permalink / raw)
To: Leo Liu; +Cc: 15808
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#15808: 24.3; thing-at-point slow for url and email
2013-11-06 2:18 ` Stefan Monnier
@ 2013-11-06 3:35 ` Leo Liu
2013-11-06 3:45 ` Leo Liu
1 sibling, 0 replies; 9+ messages in thread
From: Leo Liu @ 2013-11-06 3:35 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 15808
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)))
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#15808: 24.3; thing-at-point slow for url and email
2013-11-06 2:18 ` Stefan Monnier
2013-11-06 3:35 ` Leo Liu
@ 2013-11-06 3:45 ` Leo Liu
2013-11-06 6:55 ` Stefan Monnier
1 sibling, 1 reply; 9+ messages in thread
From: Leo Liu @ 2013-11-06 3:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 15808
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)))
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-11-06 9:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-05 2:52 bug#15808: 24.3; thing-at-point slow for url and email Leo Liu
2013-11-05 8:41 ` Andreas Röhler
2013-11-05 16:32 ` Stefan Monnier
2013-11-06 0:59 ` Leo Liu
2013-11-06 2:18 ` Stefan Monnier
2013-11-06 3:35 ` Leo Liu
2013-11-06 3:45 ` Leo Liu
2013-11-06 6:55 ` Stefan Monnier
2013-11-06 9:10 ` Leo Liu
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).