Dear OCaml folks,
when building large applications that work on complicated and highly
networked data, one issue that easily comes up is to get some idea
about what chunks of data eat all your memory. Now, it would be
marvellous for data structure optimization purposes if there were a
function
Le 23 juil. 08 à 12:54, Dr. Thomas Fischbacher a écrit :
Is there already something like that? Has anyone already built such
a tool?
Also had this wish the other day, I found objsize [1] but didn't use
it -- did a rough approximation by traversing the datastructure. A
generic implementati
>> Is there already something like that? Has anyone already built such
>> a tool?
>
> Also had this wish the other day, I found objsize [1] but didn't use
> it -- did a rough approximation by traversing the datastructure. A
I have been using Size by Jean-Christophe Filliatre. It worked fine
for me
Hello.
DTF> memory_footprint: 'a -> int64 (or maybe float),
objsize, now hosted on OCaml forge:
http://forge.ocamlcore.org/projects/objsize/
--
WBR,
dmitry mailto:[EMAIL PROTECTED]
___
Caml-list mailing list. Subscription
dmitry grebeniuk wrote:
DTF> memory_footprint: 'a -> int64 (or maybe float),
objsize, now hosted on OCaml forge:
http://forge.ocamlcore.org/projects/objsize/
Many thanks! I just had a glance at it, but it seems to be just how one
would have to approach such a problem. (The issue with hash-
Many thanks! I just had a glance at it, but it seems to be just how one
would have to approach such a problem. (The issue with hash-based
approaches to find previously visited substructures is that during
traversal, a GC may occur. Now I just assume that this may involve
relocation and heap compac
Alain Frisch wrote:
Many thanks! I just had a glance at it, but it seems to be just how one
would have to approach such a problem. (The issue with hash-based
approaches to find previously visited substructures is that during
traversal, a GC may occur. Now I just assume that this may involve
relo
Dr. Thomas Fischbacher wrote:
Alain Frisch wrote:
As long as the data structure supports the polymorphic hash function, it
should work to simply use a regular hash table with the polymorphic hash
function and physical equality, as in:
module S = Hashtbl.Make(struct
type t = Obj.t
let hash
Alain Frisch wrote:
As long as the data structure supports the polymorphic hash function, it
should work to simply use a regular hash table with the polymorphic hash
function and physical equality, as in:
module S = Hashtbl.Make(struct
type t = Obj.t
let hash = Hashtbl.hash
let equal = (=
Dr. Thomas Fischbacher wrote:
The OCaml manual gives no guarantee that Hashtbl.hash does not cons, so
I cannot assume this.
Indeed, Hashtbl.hash can cons, but this does not contradict my point:
its result does not depend on the physical location of objects in memory
(if it did, it would be im
10 matches
Mail list logo
