Re: [Caml-list] Now it's faster (addendum to "Performance-question")

["Jean-Christophe Filliâtre" <Jean-Christophe.Filliatre@lri.fr>]

Vincent Hanquez wrote:
> On Mon, Feb 11, 2008 at 11:01:37AM +0100, Jean-Christophe Filliâtre wrote:
>> Just for fun, I wrote a ropes-based implementation of Buffer. The
>> interface is exactly the same. Differences between the two
>> implementations are the following:
> 
> that's nice. how's the performance compare to plain buffer ?

I made few tests, but performance since to be roughly the same. But
there is a caveat: when creating a buffer, the value passed to create
does not have the same meaning as in Buffer, and may result in bad
performances if it is too small.

With Buffer, it will be doubled until the buffer is large enough,
involving a few string copies.

With Rbuffer, the value passed to create is the size of each chunk in
the rope (roughly), so passing a value such as 10 and then appending
millions of characters will result in a lot of allocations for rope
nodes, and will make Rbuffer less efficient than Buffer. But if you pass
a value large enough, i.e. of the same order of magnitude as the size of
the final buffer, then it should be as efficient as Buffer.

> one nit, keeping compatibility is good, however, the contents function
> is quite evil (runtime failure), and removing it would be nice as well.

I agree that a failure of "contents" can be surprising, but I don't like
the idea of removing it at all (in particular because you may want to be
able to substitute Rbuffer for Buffer in yours programs to compare
efficiencies).

> people should use other thing to "iterate" over the contents (even if
> contents is quite practical)

do you mean something like "iter : t -> (char -> unit) -> unit"?

(It could be implemented more efficiently than a repeated use of "nth")

-- 
Jean-Christophe Filliâtre
http://www.lri.fr/~filliatr/