Re: [Lib2geom-devel] C-arrays

[Nathan H. <nj...@nj...>]

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:
> ---- Nathan Hurst <nj...@nj...> wrote: 
> > I'm around, not much time though.  Is there a real benefit to porting
> > bezier-utils to vector?  I did it once before and it was a lot of work
> > and lead to some subtle bugs.  What benefit do you see?
> > 
> > I would rather we focused on careful profiling and optimisation.
> 
> The main gains I see are: exception safety / memleaks, crash safety, and maintainability/readability. Note: at zero performance cost.

But that code has been used for a decade now with no evidence of
problems, I would be loath to change it purely for stylistic reasons.
When I tried to do this, I remember that it uncovered some
mathematically unusual operations which were hard to express in
2geom.  As they were heuristics and not useful in general adding them
to say D2<> would have been ugly.  Without them the code was harder to
understand and slower.

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

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.

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

> 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

njh