Re: [Lib2geom-devel] C-arrays

[Johan E. <jbc...@sw...>]

On 6-11-2013 17:39, Nathan Hurst wrote:
> I 100% support your position, but having been down this path in the
> past I strongly advise you to take care:
>
> On Wed, Nov 06, 2013 at 05:11:33PM +0100, jbc...@sw... wrote:
>> Yes, we can work on performance optimization, but I think that's
>> pointless for code that is in a "bad" state. Note that vectors do
>> not make code slow at all
> That is not true in my experience.  Sure, there is negligible overhead
> for the access of the vector vs array, but there is definitely
> measurable overhead in the more complicated allocator.

To clear the confusion: I was talking mainly about the dynamically 
allocated C-arrays that are new'ed in that code.


> as far as bad is concerned, I would rather we worked on improving the
> api and numerical guarantees for other parts of the code.  What are
> the main reasons that we haven't completely moved to 2geom in
> inkscape?  Does someone want to take on boolops again?  Even porting
> the livarot boolops to 2geom notation would be beneficial.
>
> Another direction we could go is switching to cgal for the topology
> operators.  Now that cgal has a compatible licence we need to
> reconsider it.  The problems we had in the past (IIRC) where the
> licence, performance and accuracy.  It is likely that these are all no
> longer issues.

This will also improve the API, making it more in-sync with the rest of 
2geom.
I think boolops is a separate discussion / goal. It requires a different 
skill-set too :-)
I agree that any work on boolops would be great.

>> , and when we better integrate this
>> particular piece of code using the 'standard' 2geom types, it might
>> have the side effect of making things a little bit faster because of
>> less conversion between data structures. So my plan was: C++ify
>> code, fix the bugs that show up, see what can be improved
>> performance-wise and interface-wise.
> That seems backwards - first profile and find the problems, then fix
> the code.

I am somewhat surprised at the performance concern. There is no reason 
at all to believe the changes I propose would make code perform 
noticeably worse or better.
But yes, I already thought about first writing performance tests, just 
to prove that it won't make a difference.

>> By the way, a big reason for me to switch to C++11 is to see if it
>> would improve performance (e.g. move semantics) while maintaining
>> our high-level of abstraction. I guess we can start writing
>> performance tests/toys, to see if the changes really bring
>> anything. The new C++11 <chrono> library seems to provide portable
>> high-precision clock... I have not tested it yet though.
> We can use C++11 in 2geom for tests and leave the library itself in C++99

Yep, will do that.

Cheers,
   Johan