Perf improvement to IntLigne::Copy(FloatLigne)
I've checked in a patch to IntLigne::Copy(FloatLigne*) that improves performance on my box.
Previously, it had been taking 0.10 sec (4.74%), but now has been reduced to 0.03 sec (1.47%).
I don't think I made any algorithmic changes, and booleans seems to still be working right, but I'd appreciate it if someone could keep an eye on it in case a goof got introduced.
Bryce
Before: % cumulative self time seconds seconds name 11.85 0.25 0.25 Shape::SwapEdges(int, int) 7.11 0.40 0.15 Shape::ConvertToShape(Shape*, fill_typ, bool) 4.74 0.50 0.10 IntLigne::Copy(FloatLigne*) <---- 3.79 0.58 0.08 Shape::SwapPoints(int, int) 3.32 0.65 0.07 Shape::CmpToVert(NR::Point, NR::Point, bool, bool) ...
After: % cumulative self time seconds seconds name 13.73 0.28 0.28 Shape::SwapEdges(int, int) 7.35 0.43 0.15 Shape::ConvertToShape(Shape*, fill_typ, bool) 5.39 0.54 0.11 Shape::SwapPoints(int, int) 3.43 0.61 0.07 FloatLigne::InsertBord(int, float, int) 3.43 0.68 0.07 FloatLigne::Flatten() 3.43 0.75 0.07 Shape::TesteIntersection(SweepTree*, SweepTree*, NR::Point&, double&, double&, bool) 2.94 0.81 0.06 Shape::AddEdge(int, int) 2.45 0.86 0.05 Shape::TesteAdjacency(Shape*, int, NR::Point, int, bool) 2.45 0.91 0.05 Shape::CheckAdjacencies(int, int, Shape*, int) 1.96 0.95 0.04 Shape::CheckEdges(int, int, Shape*, Shape*, bool_op) 1.96 0.99 0.04 Shape::SortEdges() 1.47 1.02 0.03 sp_repr_attr(SPRepr const*, char const*) 1.47 1.05 0.03 IntLigne::Copy(FloatLigne*) <---- 1.47 1.08 0.03 nr_path_matrix_bbox_union(NRBPath const*, NR::Matrix const&, NRRect*) 1.47 1.11 0.03 nr_object_check_instance_type(void*, unsigned) ...
On Sat, 3 Jul 2004, Bryce Harrington wrote:
I've checked in a patch to IntLigne::Copy(FloatLigne*) that improves performance on my box.
Previously, it had been taking 0.10 sec (4.74%), but now has been reduced to 0.03 sec (1.47%).
Did a few more test runs to be sure:
2.24 1.01 0.06 6977 0.01 0.01 IntLigne::Copy(FloatLigne*) 0.81 1.74 0.02 6977 0.00 0.00 IntLigne::Copy(FloatLigne*) 1.12 1.53 0.03 6977 0.00 0.01 IntLigne::Copy(FloatLigne*) 2.89 0.74 0.07 6977 0.01 0.01 IntLigne::Copy(FloatLigne*) 2.07 1.17 0.06 6977 0.01 0.01 IntLigne::Copy(FloatLigne*)
So, it's between 0.02-0.07 sec now.
I don't think I made any algorithmic changes, and booleans seems to still be working right, but I'd appreciate it if someone could keep an eye on it in case a goof got introduced.
Bryce
I've checked in a patch to IntLigne::Copy(FloatLigne*) that improves performance on my box.
Thanks Bryce, it does help. The tutorial-basic used to take 3.0 sec on average to load, now it loads in 2.75 sec. I haven't seen any rendering problems. Still, I'd suggest that you postpone further optimizations until after the release because they are rather dangerous and not too urgent (we're already notably faster than 0.38).
On Sat, 3 Jul 2004, bulia byak wrote:
I've checked in a patch to IntLigne::Copy(FloatLigne*) that improves performance on my box.
Thanks Bryce, it does help. The tutorial-basic used to take 3.0 sec on average to load, now it loads in 2.75 sec. I haven't seen any rendering problems. Still, I'd suggest that you postpone further optimizations until after the release because they are rather dangerous and not too urgent (we're already notably faster than 0.38).
Yeah, I actually was planning on just putting the code in the patch tracker for after the release, but mental reviewed the patch and said it was worth committing, so I felt it'd be safe enough. However, yes I have decided to postpone further work until after the release.
Fwiw, I did take a look at a few more routines to see if there were obvious optimizations. Shape::SwapEdges(int,int) scored high, but I didn't see anything obvious. It appears to be mainly a big if/else chain, so I'm wondering if it could be represented as a data structure; if so, possibly the compiler could figure out better optimization paths for it.
Shape::ConvertToShape is another one that could use attention. The reason it is at the top of the profiling list is because it's just such a _long_ function. It probably could benefit from being broken up into some sub-functions, as it is around 800 lines currently.
Bryce
participants (2)
-
Bryce Harrington -
bulia byak