[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: byte-compiler very slow (cont.)
From: |
David Ponce |
Subject: |
Re: byte-compiler very slow (cont.) |
Date: |
Tue, 23 Jul 2002 15:25:08 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020720 |
Hi,
I continued to work on byte-compiler slow down and also found that,
in certain cases, the function `byte-compile-set-symbol-position' can
sensibly impact the performance.
A such example is wisent-java.el (the Java LALR automaton part of
Semantic toolkit) which contains an array of 293 very short lambda
forms (the semantic actions to apply when reducing rules). This array
is byte-compiled by the function `wisent-semantic-actions' that, in
fact, calls `byte-compile' on each array element. After profiling I
found the following (I disabled checking of 'cl-functions warnings,
see my previous post):
Function Name Call Count Elapsed Time Average Time
======================= ========== ============ ============
wisent-semantic-actions 1 23.324 23.324
byte-compile-set-symbol-position 17749 19.979 0.001126
Showing that the time spent in `byte-compile-set-symbol-position' is
not negligible!
I significantly improved that result with the following patch:
*** bytecomp.el.ori Sun Jul 21 01:14:04 2002
--- bytecomp.el Tue Jul 23 15:02:35 2002
***************
*** 848,854 ****
"Last known character position in the input.")
;; copied from gnus-util.el
! (defun byte-compile-delete-first (elt list)
(if (eq (car list) elt)
(cdr list)
(let ((total list))
--- 848,854 ----
"Last known character position in the input.")
;; copied from gnus-util.el
! (defsubst byte-compile-delete-first (elt list)
(if (eq (car list) elt)
(cdr list)
(let ((total list))
***************
*** 872,889 ****
;; gross hack? And the answer, of course, would be yes.
(defun byte-compile-set-symbol-position (sym &optional allow-previous)
(when byte-compile-read-position
! (let ((last nil))
(while (progn
! (setq last byte-compile-last-position)
! (let* ((entry (assq sym read-symbol-positions-list))
! (cur (cdr entry)))
! (setq byte-compile-last-position
! (if cur
! (+ byte-compile-read-position cur)
! last))
! (setq
! read-symbol-positions-list
! (byte-compile-delete-first entry read-symbol-positions-list)))
(or (and allow-previous (not (= last
byte-compile-last-position)))
(> last byte-compile-last-position)))))))
--- 872,887 ----
;; gross hack? And the answer, of course, would be yes.
(defun byte-compile-set-symbol-position (sym &optional allow-previous)
(when byte-compile-read-position
! (let (last entry)
(while (progn
! (setq last byte-compile-last-position
! entry (assq sym read-symbol-positions-list))
! (when entry
! (setq byte-compile-last-position
! (+ byte-compile-read-position (cdr entry))
! read-symbol-positions-list
! (byte-compile-delete-first
! entry read-symbol-positions-list)))
(or (and allow-previous (not (= last
byte-compile-last-position)))
(> last byte-compile-last-position)))))))
With the above patch applied, profiling gave me:
Function Name Call Count Elapsed Time Average Time
======================= ========== ============ ============
wisent-semantic-actions 1 4.787 4.787
byte-compile-set-symbol-position 17749 1.371 7.772e-005
What do you think?
Sincerely,
David
- byte-compiler very slow, David Ponce, 2002/07/20
- Re: byte-compiler very slow, David Ponce, 2002/07/21
- Re: byte-compiler very slow, Richard Stallman, 2002/07/21
- Re: byte-compiler very slow, Colin Walters, 2002/07/21
- Re: byte-compiler very slow, Richard Stallman, 2002/07/22
- Re: byte-compiler very slow, David Ponce, 2002/07/23
- Re: byte-compiler very slow, Richard Stallman, 2002/07/23
- Re: byte-compiler very slow, David Ponce, 2002/07/24
- Re: byte-compiler very slow, Richard Stallman, 2002/07/24
- Re: byte-compiler very slow (cont.),
David Ponce <=