[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile Binary Format 0.0

From: Keisuke Nishida
Subject: Re: Guile Binary Format 0.0
Date: Sat, 03 Feb 2001 15:14:26 -0500
User-agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/21.0.96 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)

At 03 Feb 2001 19:18:15 +0200,
Michael Livshin wrote:
> if I may offer my paranoid opinion...
> I don't like this.  if you group objects according to their type and
> not according to their relation to each other, you break data
> locality.  the loaded image may perform much worse then it did before
> saving.

Hmm, I'm not sure about this.  Objects are reallocated anyway.
When I think about bytecode,

1. Cells are allocated from Guile's heap
2. Symbols and variables are allocated in a global space
3. Bytecodes are on the mmap'ed memory
4. Other constants excepts immediates are allocated by
   a sequential malloc

So, locality will be lost anyway.  Probably we should benchmark it
with a real application.

But surely, I didn't think of locality.  If the current code works
bad, I will rewrite it.

> I don't think it's very important to heavily optimize saving/loading
> time, as these operations are dominated by I/O anyway.

Yes.  My point was to reduce file size and so I/O.

> so it would be good to find a nice combination of good object grouping
> and small file size.  the best way (to me) is to dump raw memory, more
> or less, and "patch" it upon restoring.  would that be doable?

I tried it a long ago, which was quite complicated.  Maybe someone
should write it in the future and compare it with my current code.

I don't think it's time to optimize things.  I'm going to finish
my byte compiler and vm first, and test them with this loader.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]