emacs-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]