From: Alex Baretta <alex@barettadeit.com>
To: Ocaml <caml-list@inria.fr>
Subject: Impact of GC on memoized algorithm
Date: Wed, 30 Mar 2005 10:39:32 +0200 [thread overview]
Message-ID: <424A65C4.2080507@barettadeit.com> (raw)
I am trying to fine tune a "cut stock" optimization algorithm which I
have written for Ocaml. It so happens that the vanilla recursive
implementation is quite fast, relatively to other implementations I've
seen, whereas the memoized implementation is very slow. The vanilla
implementation has a memory footprint of only a few megabytes, whereas
the memoized version takes up some 60 MB on the same input. Quite
obviously, the hashtable used to cache the results suffers from the
combinatorial explosion of possible inputs. Now, given this, it is
expected that the memoized version be as slow or slightly slower than
the non memoized version, but it is not obvious why it would be a couple
of orders of magnitude slower.
I have come to think that the difference in performance might be
attributable to the garbage collector. This might be the case if the
complexity of a collection is proportional to the total allocated
memory, because the overall allocation/reclaiming cost of a fresh block
would be proportional to the total number of allocated blocks.
Is my diagnosis correct? That is, is the GC collection a O(n) algorithm?
Would the C-language malloc/free model be any faster here? As far as I
know malloc keeps a linked list of free blocks, which is also O(n).
Alex
--
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL
tel. +39 02 370 111 55
fax. +39 02 370 111 54
Our technology:
The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>
The FreerP Project
<http://www.freerp.org/>
next reply other threads:[~2005-03-30 9:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-30 8:39 Alex Baretta [this message]
2005-03-30 12:03 ` [Caml-list] " Jon Harrop
2005-03-30 12:34 ` Alex Baretta
2005-03-30 13:09 ` Alexander S. Usov
2005-03-30 13:56 ` Marcin 'Qrczak' Kowalczyk
2005-03-30 15:03 ` Alex Baretta
2005-03-31 14:41 ` Jean-Christophe Filliatre
2005-04-11 14:22 ` Damien Doligez
2005-04-11 15:48 ` Alex Baretta
2005-04-14 9:52 ` Damien Doligez
2005-04-14 10:27 ` Jan Kybic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=424A65C4.2080507@barettadeit.com \
--to=alex@barettadeit.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox