Boost logo

Boost :

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2001-05-25 08:16:54

Beman Dawes wrote:

> At 08:31 PM 5/23/2001, Larry Evans wrote:
> >The gc_sel_ssp.doc file which I've just uploaded has a comparison
> >of some existing boost gc methods.
> Very interesting... Thanks!
> Some initial impressions on ways to improve the documents:
> * It would be helpful to use fuller names to identify the methods. A name
> like "jrg_gc" should get expanded to "John's really good garbage
> collector" or whatever it stands for.

I'll try.

> * The "Comparisons" might be renamed "Analysis" as it seems that would be
> a more accurate description.


> * A "Comparison" table, perhaps with methods as columns and distilled
> analysis points as rows would make actual comparisons between methods a lot
> easier.


> * For the memory usage analysis, it would be useful to pick one or two
> typical graphs, and compute the actual memory size used (making some
> typical assumptions about sizeof pointers, longs, etc). While the basis
> has to be your detailed analysis, actual numbers are a lot easier to
> compare.


> * I'm not sure if it is possible to do something similar for timings, but
> it would be useful to know somehow the relative speeds in typical
> small/medium/large uses (if there is such a thing).

Ok. I've found it difficult to do this analysis because of if statements
and switches ... One example is cyclic_ptr's recycler::recycle method
where the time depends on the largest value of V.size, but only
weakly since a simple test is used to detect an invalid handle.

Your small/medium/large use comment is especially relevant since
the other two methods analyzed so far find the roots by exhaustively
searching the heap. This is the main reason I suggested cyclic_ptr
would be better, although I haven't bothered yet to be more thorough
in the comparison. I'm also thinking of raising the issue of why
Boehm's collector shouldn't be used. The only reason I can think
of is the remote possiblity of misidentifying pointers. This is the
point raised by others, but it's especially relevant because this
only becomes a problem with dense pointer graphs, which is the
very place where the other methods, I suspect, will grind to a crawl.
(Again, the last statement was made without any testing. It's
just a first [or maybe 13th :)] impression.)

> Anyhow, this is really interesting stuff and I hope others will take a look
> at your work and make comments.

Thanks for the detailed feedback. Your comments were helpful.

Boost list run by bdawes at, gregod at, cpdaniel at, john at