[Top][All Lists]

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

Re: Guile Binary Format 0.0

From: Dirk Herrmann
Subject: Re: Guile Binary Format 0.0
Date: Sun, 4 Feb 2001 17:59:30 +0100 (MET)

On Sat, 3 Feb 2001, Keisuke Nishida wrote:

> > * A lot of the complexity of the storing/reloading mechanism seems to come
> > from the fact that your binary format requires to have a list of all
> > objects before an object is actually being written, because you have your
> > 'meta section'.  If the information from the meta section was placed in
> > between the object data 'on demand', an initial marking phase was
> > unnecessary, the same would hold for a final storing phase.
> This is more or less what I did before.  While it works, my current
> approach has advantages that it consumes less disk space and
> (possibly) less loading time.
> In my approach, I don't need to store a tag at the beginning of each
> object.  If the number of objects stored is very large, this may be
> significant.  While we have huge disks, I guess less disk space is
> good for fast loading.

My major concern is the implementation complexity of the other approach.  
While you are right, though, that there is an overhead for storing
objects, I doubt that it is significant and worth the added complexity.

> Moreover, we can avoid load-time dispatch due to the meta section
> (It's not "meta", I guess...)  Since objects of the same type are
> sequentially placed, we can reconstruct them in a small loop (see
> scm_undump_alloc).  I guess this is also good for fast loading.

Hmmm.  Your 'sorting according to type' approach can make loading of a
single object take an arbitrary long time.  Assume that a binary file was
created by first writing an integer, then writing a symbol, and then
writing 10^n integers (choose n arbitrarily large).  Later, this file is
to be reread.  First, you read an integer, then you read a symbol, then
the file is closed, because for some reason the remaining integers are not
needed.  How long does it take to read the symbol?  With your approach it
can take quite a long time, if you first have to skip all the 10^n
integers to reach the point where the symbol is stored...

> foo_undump (SCM dstate)
> {
>   struct foo *p = scm_must_malloc (sizeof (struct foo), "foo_undump");
>   scm_undump_word (&p->x, dstate);
>   scm_undump_word (&p->y, dstate);
>   scm_undump_object (&p->bar, dstate);
>   scm_undump_object (&p->baz, dstate);
>   SCM_RETURN_NEWSMOB (scm_tc16_foo, p);
> }

Yes, you are right.  This is nicer.

Best regards,
Dirk Herrmann

reply via email to

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