From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Enlarge MAX_ALLOCA? Date: Sat, 21 Jun 2014 16:59:37 +0300 Message-ID: <83egyitlbq.fsf@gnu.org> References: <874mzetnzv.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1403359210 17779 80.91.229.3 (21 Jun 2014 14:00:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Jun 2014 14:00:10 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: handa@gnu.org (K. Handa) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 21 16:00:03 2014 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 1WyLpq-0006XW-PQ for ged-emacs-devel@m.gmane.org; Sat, 21 Jun 2014 16:00:02 +0200 Original-Received: from localhost ([::1]:45084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyLpq-0005J1-96 for ged-emacs-devel@m.gmane.org; Sat, 21 Jun 2014 10:00:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyLpi-0005Ij-Lp for emacs-devel@gnu.org; Sat, 21 Jun 2014 09:59:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WyLpd-00028s-Ge for emacs-devel@gnu.org; Sat, 21 Jun 2014 09:59:54 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:62149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WyLpd-00028h-8f; Sat, 21 Jun 2014 09:59:49 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N7I00G00UDS3700@a-mtaout20.012.net.il>; Sat, 21 Jun 2014 16:59:47 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7I00GF8UVN7000@a-mtaout20.012.net.il>; Sat, 21 Jun 2014 16:59:47 +0300 (IDT) In-reply-to: <874mzetnzv.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:172606 Archived-At: > From: handa@gnu.org (K. Handa) > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sat, 21 Jun 2014 22:01:56 +0900 > > In article <83lhsssq1b.fsf@gnu.org>, Eli Zaretskii writes: > > > That buffer is fixed in size, I don't know what. Perhaps it's hard to > > know in advance how much we will need. I hope Handa-san could explain. > > The reason of making it fixed size is that I was just lazy > and didn't expect that decoder/encoder were called so > frequently. :-( The reaons of 0x4000 was that most of the > elisp files in lisp/language were less than 0x4000 > characters. > > And, yes, we can estimate the actually necessarey > CHARBUF_SIZE as coding->src_bytes on decoding, and > coding->src_chars on encoding. Does the patch below look OK to you? I tried it, but it seems to cause trouble when byte-compiling: Emacs enters some kind of infloop. Perhaps I misunderstood what you meant? > By the way, perhaps the most effective way for making > ENCODE_FILE faster and less memory-touching is to change > encode_file_name return FNAME when FNAME contains ASCII > only or file-name-coding-system is utf-8. This would be a good improvement, as most platforms we care about use UTF-8 for file-name encoding these days. Could you please suggest such changes? TIA === modified file 'src/coding.c' --- src/coding.c 2014-04-05 19:30:36 +0000 +++ src/coding.c 2014-06-21 13:47:39 +0000 @@ -7265,13 +7265,10 @@ produce_charset (struct coding_system *c coding->dst_object); } - -#define CHARBUF_SIZE 0x4000 - -#define ALLOC_CONVERSION_WORK_AREA(coding) \ +#define ALLOC_CONVERSION_WORK_AREA(coding, size) \ do { \ - coding->charbuf = SAFE_ALLOCA (CHARBUF_SIZE * sizeof (int)); \ - coding->charbuf_size = CHARBUF_SIZE; \ + coding->charbuf = SAFE_ALLOCA ((size) * sizeof (int)); \ + coding->charbuf_size = (size); \ } while (0) @@ -7373,7 +7370,7 @@ decode_coding (struct coding_system *cod record_conversion_result (coding, CODING_RESULT_SUCCESS); coding->errors = 0; - ALLOC_CONVERSION_WORK_AREA (coding); + ALLOC_CONVERSION_WORK_AREA (coding, coding->src_bytes); attrs = CODING_ID_ATTRS (coding->id); translation_table = get_translation_table (attrs, 0, NULL); @@ -7769,7 +7766,7 @@ encode_coding (struct coding_system *cod record_conversion_result (coding, CODING_RESULT_SUCCESS); coding->errors = 0; - ALLOC_CONVERSION_WORK_AREA (coding); + ALLOC_CONVERSION_WORK_AREA (coding, coding->src_chars); if (coding->encoder == encode_coding_ccl) {