From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Loading souce Elisp faster Date: Thu, 28 Feb 2013 23:10:57 +0900 Message-ID: <87wqtssf4e.fsf@gnu.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1362060682 4549 80.91.229.3 (28 Feb 2013 14:11:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Feb 2013 14:11:22 +0000 (UTC) Cc: lennart.borgman@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 28 15:11:44 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UB4Cx-0005jk-Eb for ged-emacs-devel@m.gmane.org; Thu, 28 Feb 2013 15:11:39 +0100 Original-Received: from localhost ([::1]:33117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB4Cc-0004iP-8t for ged-emacs-devel@m.gmane.org; Thu, 28 Feb 2013 09:11:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB4CY-0004fK-Cz for emacs-devel@gnu.org; Thu, 28 Feb 2013 09:11:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UB4CT-00086i-OS for emacs-devel@gnu.org; Thu, 28 Feb 2013 09:11:14 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB4CT-00086b-6r for emacs-devel@gnu.org; Thu, 28 Feb 2013 09:11:09 -0500 Original-Received: from 253.240.accsnet.ne.jp ([202.220.240.253]:37555 helo=mongkok) by fencepost.gnu.org with esmtpa (Exim 4.71) (envelope-from ) id 1UB4CL-0001GC-FC; Thu, 28 Feb 2013 09:11:01 -0500 In-Reply-To: (message from Richard Stallman on Wed, 27 Feb 2013 09:28:09 -0500) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157454 Archived-At: In article , Richard Stallman writes: > This change in decode_coding_utf_8 should make it considerably faster > in the usual case where few characters need conversion. Even with that change, the decoder still copies the source bytes to the array coding->charbuf, then store characters in coding->charbuf into the destination buffer. I think the better place of tuning is in the function decode_coding. It has do-while loop that basically does this: do { /* decode the source bytes and store characters in charbuf */ (*(coding->decoder)) (coding); /* insert characters of charbuf in the destination buffer. */ produce_chars (coding, translation_table, 0); } while (...) We can change that to: do { int ascii_bytes = find_ascii_chars_in_source (coding); if (ascii_bytes > SHORT_CUT_THRESHOLD) { /* Copy source bytes directly to destination buffer. For reading a buffer, source bytes are in a gap area of the destination buffer. So, with careful programming, we may even be able to avoid this coping. */ } else { (*(coding->decoder)) (coding); produce_chars (coding, translation_table, 0); } } while (...) --- Kenichi Handa handa@gnu.org