CGAL users discussion list

[Philipp Moeller <>]

Stefan Schirra 
<>
 writes:

> On 02.03.2012 16:08, Marc Glisse wrote:
>> On Fri, 2 Mar 2012, Zohar wrote:
>>
>>> 1. Why is the Simple_Cartesian better than the Cartesian?
>>>
>>> I found in the doc of simple_cart:
>>>
>>> "In contrast to Cartesian, no reference counting is used internally. This
>>> eases debugging, but may slow down algorithms that copy objects
>>> intensively."
>>
>> It is not better in general. When the number type is double, the heavy 
>> reference
>> counting machinery has only drawbacks (copying a pair of double takes no 
>> time):
>> dynamic allocation, thread-unsafe. When the number type is something heavy 
>> (say
>> mpq_class or some other bignum that is not already reference-counted) and 
>> you do
>> a lot a copying objects around, it can be a life-saver.
>
> Sorry Marc, I do not fully agree.
>
> Thread-safety is certainly an issue. However, even copying pairs of
> doubles takes some time. It is not clear whether it takes more time
> than copying a pointer and incrementing an int. Even if it would, your
> application must copy a lot, because of the indirection in the access
> operations (cache effects are an issue as well). So it depends. For
> more, probably somewhat outdated, information on this issue, see
> "S. Schirra; A Case Study on the Cost of Geometric Computing. In
> Algorithm Engineering and Experimentation (ALENEX99), pages 156-176,
> 1999. Springer, Berlin. Note: LNCS 1619.
>
> For "heavy number types", you can usually use Simple_cartesian,
> because mpq_class and other bignum integers already use reference
> counting themselves! So you don't copy bignums anyway.
>
>
> --Stefan

Maybe we should consolidate this information in a page? The current FAQ
is a little too vague and slightly too optimistic about reference
counting, IMO. The choice can have a large impact on the performance and
a lot of users are probably making a sub-optimal decision without
knowing it. Also, the naming Simple_cartesian/Cartesian is less than
optimal but we would have a hard time fixing that.

-- 
Philipp