Re: Guile Binary Format 0.0

[Keisuke Nishida]

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.

Kei