Re: Guile Binary Format 0.0

[Keisuke Nishida]

At Sun, 4 Feb 2001 17:59:30 +0100 (MET),
Dirk Herrmann wrote:
> 
> 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.

Okay, probably it's not worth doing, though it's not hard anyway.
Probably what is more important is to reduce the complexity of
interface.  I'll rethink about it.

> 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...

It depends on how you store them.  If you store them separately,
separate sections are created.

  (binary-write 1000 port)
  (binary-write 'foo port)
  (binary-write 2000 port)

yields something like

  [GBF ][   0][1000]
  [GBF ]]   1][  #0][symbol][foo]
  [GBF ][   0][1000]

and you restore them in the same order as you stored.

On the other hand,

  (binary-write #(1000 foo 2000) port)

yields

  [GBF ][  2][  #0][vector][   3][1000][  #1][2000][symbol][foo]

and they are restored at once.  In this case, your concern may
happen, but you want the whole vector anyway.

Kei