From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Ponce Newsgroups: gmane.emacs.devel Subject: Re: byte-compiler very slow (cont.) Date: Tue, 23 Jul 2002 15:25:08 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <3D3D5934.6000205@dponce.com> References: <3D39C79B.6020605@dponce.com> <200207212015.g6LKFgA00958@aztec.santafe.edu> <1027284727.5453.5.camel@space-ghost> <200207221519.g6MFJnK02311@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1027430606 12317 127.0.0.1 (23 Jul 2002 13:23:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 23 Jul 2002 13:23:26 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17WzdN-0003CY-00 for ; Tue, 23 Jul 2002 15:23:25 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Wzri-0004Wd-00 for ; Tue, 23 Jul 2002 15:38:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17WzdP-0007Ot-00; Tue, 23 Jul 2002 09:23:27 -0400 Original-Received: from smtp-out-6.wanadoo.fr ([193.252.19.25] helo=mel-rto6.wanadoo.fr) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17WzcM-0007MA-00; Tue, 23 Jul 2002 09:22:23 -0400 Original-Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto6.wanadoo.fr (6.5.007) id 3D18683700ED3BEE; Tue, 23 Jul 2002 15:22:21 +0200 Original-Received: from dponce.com (80.9.191.101) by mel-rta7.wanadoo.fr (6.5.007) id 3D2A78FA006A98AD; Tue, 23 Jul 2002 15:22:21 +0200 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020720 X-Accept-Language: fr, en-us, en Original-To: rms@gnu.org Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5989 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5989 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