From: Krzysztof K. <twe...@gm...> - 2010-02-10 15:27:27
|
W dniu 9 lutego 2010 09:58 użytkownik <J.B...@ew...> napisał: > Krzysztof, > > Perhaps you could make minimal test cases, to see what performance gain you get when you change things? I think Mental made some timer/performance checking code, for Linux. > > I am glad too that you are working on performance, and hope you can achieve good results. (I am a little in doubt whether these specific changes you propose will do much, but still :-) The goal is not only improving performance, but also improving the usability of the library. Changing to boost::ptr_vector will reduce the memory footprint and halve the number of allocations required to create a given path. Currently an allocation must be done twice for every curve stored in the path: once for the curve itself and the second time for the shared pointer's reference count. We need to do this for every curve, because the curves are not shared between paths and the smart pointers are only needed to implement ownership semantics. Another area of improvement are transferring sequence operations: it will be possible to move curves between paths without copying them. They will be modeled after the semantics of boost::ptr_vector's transfer operation but adjusted for the case of paths. BTW I want to make 2 additional changes: 1. When the ends of normal path data coincide, no closing segment is added. 2. Stitching is mandatory. Extra segments are inserted only when the new elements introduce gaps. If the endpoints coincide, no extra segments are introduced. 2 is done to introduce an invariant that the path is always continuous. This way exceptions may only be thrown when inserting new elements into a path, not at some random time when using it. It complements the closing segment idea. Once transferring sequence operations are introduced, non-stitching operations won't be of much use anyway. Regards, Krzysztof |