[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enlarge MAX_ALLOCA?
From: |
K. Handa |
Subject: |
Re: Enlarge MAX_ALLOCA? |
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.
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.
---
Kenichi Handa
address@hidden
- Re: Enlarge MAX_ALLOCA?, (continued)
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/19
- 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 <=
- Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/21
- 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