2014-03-01 19:08 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sat, 1 Mar 2014 17:00:18 +0100
> > Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> >
> > Only a couple (actualy 5 or 6 at most) of them occur, except during the
> > loading of charset maps.
> > While loading charset maps, big vectors are allocated and freed right
> away
> > many times.
> >
> > What I'm saying is that basically, all those big chunks could be made
> > static.
>
> Are you talking about the big chunks used for charset maps, or about
> the rest of them?  If the latter, what are they used for?  Which code
> causes them to be allocated?
>

The rest of them.
When doing 'temacs -batch -l loadup dump'
there are 4 occurences before loading the charset maps.
They all belong to make-hash-table

(gdb) run -batch -l loadup dump
Starting program: C:\source\gnu\emacs\mingw\src/temacs.exe -batch -l loadup
dump
[New Thread 59040.0xb09c]
Loading loadup.el (source)...
[New Thread 59040.0x113c]

#0  e_malloc (size=1120016) at w32heap-new.c:359
#1  0x00000004000f1b21 in lisp_malloc (nbytes=nbytes@entry=1120016,
    type=type@entry=MEM_TYPE_VECTORLIKE) at alloc.c:893
Lisp Backtrace:
"make-hash-table" (0x83edf0)
"setq" (0x83ef68)
"if" (0x83f058)
"load" (0x83f750)
(gdb) c

They all have the same elisp backtrace, the next sizes are:
nbytes=nbytes@entry=560016,
nbytes=nbytes@entry=560016,
nbytes=nbytes@entry=700040,

Then we have a bunch of :
Lisp Backtrace:
"define-charset-internal" (0x83e398)
"apply" (0x83e540)
"define-charset" (0x83e770)
"byte-code" (0x83e970)
"load" (0x83f060)
"load" (0x83f750)

and then of :
Lisp Backtrace:
"map-charset-chars" (0x83e7d0)
"byte-code" (0x83e970)
"load" (0x83f060)
"load" (0x83f750)

and last 3 occurences of :
size=size@entry=786440
Lisp Backtrace:
"decode-char" (0x83e798)
"byte-code" (0x83e970)
"load" (0x83f060)
"load" (0x83f750)

And after looking more carefully, all those chunks are released before
dumping!
So I could really handle them differently and shrink the data area which is
dumped.
Well, unfortunately, maybe it is not a future proof assumption.

Fabrice