Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Estimating the size of the ocaml community
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-02-04 (13:43)
From: Richard W. M. Jones <rich@m...>
Subject: Re: [Caml-list] Estimating the size of the ocaml community
On Fri, Feb 04, 2005 at 01:51:36PM +0100, Gerd Stolpmann wrote:
> Sure, this is an option, but I think the price is quite high. A number of
> frequently used data structures would need a lot more memory, and would
> become slower. For example lists. Currently, every list element needs
> three words (header + contents + reference to next element). If the
> variant tag is not part of the header, another word is needed = 33 %
> more space. There are similar effects for many basic data
> structures, including options, trees and hash tables.

Actually, I wouldn't want to change lists.  Those currently have a tag
= 0, and it would important to leave those untouched for exactly the
reason you described.

Of course, now you've pointed out the flaw in my argument, which is
that lists would be handled differently from constructs :-)

> If one wanted really to improve the situation, it would be better to change
> the representation of strings, and to encode the string length in the
> first word after the header. This wastes much less memory (except in the
> special case when you have many small strings), and is probably neutral
> for the execution speed.

But then you'd need a special case to handle values-containing-
strings, vs. values-not-containing strings, because you'd always want
to have the size attribute of the header reflect the size of the data
in the value.


Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology -
Team Notepad - intranets and extranets for business -