Browse thread
[Caml-list] Slow GC problem
[
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: | Shivkumar Chandrasekaran <shiv@e...> |
| Subject: | Re: [Caml-list] Slow GC problem |
I took Damien's advice (thanks) and spent some time trying to re-use all the bigarrays I was allocating. However, my bigarray use is spread out over a fairly complicated algorithm, and the only way to make a good dent on bigarray use would be to completely rewrite the algorithm in a more traditional fortran77 style. Which would of course mean that I would have to first figure out the entire memory usage pattern. ...... So I am pondering another solution: What if I modified bigarray_stubs.c to use the malloc and free calls of the Boehm gc (6.1-4) garbage collector? My reasoning is that malloc is performing poorly due to fragmentation, and switching to a gc'd version might help out. Before I try this I would like some feedback from the list on the soundness of this idea. Thanks, --shiv-- On Tuesday, April 8, 2003, at 03:23 AM, Damien Doligez wrote: >> I have a gc efficiency problem for which I require some advice. I >> have read both the O'Reilly book and the manual on gc. > [...] >> Below I give the gc stats just before and after the solver routine >> is called in the in-core solver: >> >> "Just before" "Just after" >> minor_words: 46243376 139259767 >> promoted_words: 928267 2595523 >> major_words: 2883087 39489766 >> minor_collections: 1412 4591 >> major_collections: 18 52 >> heap_words: 2150400 1044480 >> heap_chunks: 35 17 >> top_heap_words: 2150400 5038080 >> live_words: 1842373 840037 >> live_blocks: 253926 116816 >> free_words: 307180 204440 >> free_blocks: 47368 17 >> largest_free: 10928 61440 >> fragments: 847 3 >> compactions: 0 2 > > As others have said, this is not really enough information to tell > what is going on. What we can say from the above is: > > 1. You are allocating lots and lots of data structures in the major > heap (maybe finalized bigarray descriptors) > 2. The compactor was called twice, which may indicate that you have > a fragmentation problem. > 3. The compactor was called near the end of the solver routine, > which must have erased most of the evidence... > > -- Damien > --shiv-- ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners