Browse thread
Impact of GC on memoized algorithm
-
Alex Baretta
-
Jon Harrop
-
Alex Baretta
-
Alexander S. Usov
-
Marcin 'Qrczak' Kowalczyk
-
Alex Baretta
- Damien Doligez
- Jean-Christophe Filliatre
-
Alex Baretta
-
Marcin 'Qrczak' Kowalczyk
-
Alexander S. Usov
-
Alex Baretta
-
Jon Harrop
[
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 Filliatre <Jean-Christophe.Filliatre@l...> |
| Subject: | Re: [Caml-list] Impact of GC on memoized algorithm |
Marcin 'Qrczak' Kowalczyk wrote: > > No, OCaml's hash tables are resized automatically. Alex Baretta writes: > > Ok. So, just as I expected, I am guaranteed that I have no hash > conflicts desperately degrading the performance of my algorithm. Note that it is true only if your hash function is good enough. I had once a code spending most of its time in the resizing of Ocaml's hash tables because of a bad hash function. This is particularly true of the ocaml default hash function on ``pure'' abstract syntax trees (recursive data types with few types such as int or strings). Writing my own hash function immediately solved the performance issue. (In your case, however, the problem seems to be elsewhere ince you are using unique integers as keys). As somebody already said, a profiling is a simple way to find out if the hash tables resizing is the issue. Best regards, -- Jean-Christophe