Re: [boost] Smart pointer status, directions, thoughts

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.

Yes.

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

Yes.

>
>
> *  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.

OK.

>
>
> *  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.