[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enlarge MAX_ALLOCA?
From: |
Eli Zaretskii |
Subject: |
Re: Enlarge MAX_ALLOCA? |
Date: |
Sat, 21 Jun 2014 16:59:37 +0300 |
> From: address@hidden (K. Handa)
> Cc: address@hidden, address@hidden
> Date: Sat, 21 Jun 2014 22:01:56 +0900
>
> In article <address@hidden>, Eli Zaretskii <address@hidden> 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)
{
- Re: Enlarge MAX_ALLOCA?, (continued)
- Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/19
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
- RE: Enlarge MAX_ALLOCA?, Herring, Davis, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Dmitry Antipov, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
- Re: Enlarge MAX_ALLOCA?, K. Handa, 2014/06/21
- Re: Enlarge MAX_ALLOCA?,
Eli Zaretskii <=
- Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/21
- Re: Enlarge MAX_ALLOCA?, K. Handa, 2014/06/22
- Re: Enlarge MAX_ALLOCA?, K. Handa, 2014/06/28
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/28
- Re: Enlarge MAX_ALLOCA?, David Kastrup, 2014/06/21