Browse thread
Now it's faster (addendum to "Performance-question")
-
Oliver Bandel
-
Oliver Bandel
-
tab@s...
- David Teller
- Oliver Bandel
- Jean-Christophe_Filliātre
-
tab@s...
-
Oliver Bandel
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jean-Christophe_Filliātre <Jean-Christophe.Filliatre@l...> |
| Subject: | Re: [Caml-list] Now it's faster (addendum to "Performance-question") |
Vincent Hanquez wrote:
> the buffer library is actually pretty bad since it's actually just a
> simple string. each time the buffer need to grow, the string is
> reallocated and the previous one is copied to the new string.
> and you got the 16mb limit (max_string_length) on 32bit.
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:
- Contrary to ocaml's standard library, a buffer size is not limited to
[Sys.max_string_length], but to [max_int] (sizes are represented
internally using native ocaml integers).
- [contents] and [sub] raise [Invalid_argument] if the resulting string
would be larger than [Sys.max_string_length] bytes.
- The meaning of [create]'s argument is not exactly the same,
though its value only affects performances, as for [Buffer];
see below.
- An additional function [print] is provided.
The code is here:
http://www.lri.fr/~filliatr/ftp/ocaml/ds/rbuffer.mli
http://www.lri.fr/~filliatr/ftp/ocaml/ds/rbuffer.ml
For general-purpose ropes, see
http://www.lri.fr/~filliatr/software.en.html
--
Jean-Christophe