Startup slowdown caused by nr_arena_updates?
Hi all (and Johan in particular because it regards one of your commits),
apparently rev #18921 introduced a significant slowdown in Inkscape's startup procedure (that's what git-bisect says). I'm not sure what the issue really is but after starting Inkscape, my CPU stays extremely busy for about 20 seconds or so. During that time, drawing operations and other actions respond considerably more slowly.[1] After about 20 seconds, everything seems to work as usual again, and all operations are reasonably fast. Anyone else seeing this?
Here is a typical backtrace after interrupting Inkscape in gdb:
#0 0x08241eb2 in Geom::D2Geom::Bezier::D2 () #1 0x08241ff6 in Geom::BezierCurve<1u>::BezierCurve () #2 0x082420b6 in Geom::Path::Path () #3 0x084d6ea8 in Geom::Path::operator* () #4 0x087fc9af in Geom::operator* () #5 0x084859e9 in nr_arena_shape_update () #6 0x0847cf70 in nr_arena_item_invoke_update () #7 0x0847ec8f in nr_arena_group_update () #8 0x0847cf70 in nr_arena_item_invoke_update () #9 0x0847ec8f in nr_arena_group_update () #10 0x0847cf70 in nr_arena_item_invoke_update () #11 0x0847ec8f in nr_arena_group_update () #12 0x0847cf70 in nr_arena_item_invoke_update () #13 0x0847ec8f in nr_arena_group_update () #14 0x0847cf70 in nr_arena_item_invoke_update () #15 0x084283c2 in sp_icon_doc_icon () #16 0x084291ee in load_svg_pixels () #17 0x084292f9 in prerender_icon () #18 0x08429d24 in icon_prerender_task () #19 0xb7340c91 in ?? () from /usr/lib/libglib-2.0.so.0 #20 0x00000000 in ?? ()
Note the several calls to nr_arena_group_update() and nr_arena_item_invoke_update(). The precise 2geom routines usually vary, but I see these two calls consistently during the slowed down phase.
Hope this helps; it would be nice to have it fixed (I need to start Inkscape pretty often for testing, and this slowdown makes it quite annoying).
Many thanks, Max
[1] I first noticed this by drawing a star and converting it to a path (Shift+Ctrl+C) directly after startup, during which the cursor kept its hourglass state for about 15s. It doesn't seem to be related to path conversion, though.
:-(
I changed bbox calculation to use the 2geom path instead of NArtBpath. I'll do some tests whether this is much slower. Right now I am thinking this is very bad news for my project: it might mean that path transformation (operator*) is significantly slower in the 2geom lib than NR lib... Hoping this first hunch is wrong, Johan
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Maximilian Albert Sent: maandag 16 juni 2008 16:10 To: inkscape Subject: [Inkscape-devel] Startup slowdown caused by nr_arena_updates?
Hi all (and Johan in particular because it regards one of your commits),
apparently rev #18921 introduced a significant slowdown in Inkscape's startup procedure (that's what git-bisect says). I'm not sure what the issue really is but after starting Inkscape, my CPU stays extremely busy for about 20 seconds or so. During that time, drawing operations and other actions respond considerably more slowly.[1] After about 20 seconds, everything seems to work as usual again, and all operations are reasonably fast. Anyone else seeing this?
Here is a typical backtrace after interrupting Inkscape in gdb:
#0 0x08241eb2 in Geom::D2Geom::Bezier::D2 () #1 0x08241ff6 in Geom::BezierCurve<1u>::BezierCurve () #2 0x082420b6 in Geom::Path::Path () #3 0x084d6ea8 in Geom::Path::operator* () #4 0x087fc9af in Geom::operator* () #5 0x084859e9 in nr_arena_shape_update () #6 0x0847cf70 in nr_arena_item_invoke_update () #7 0x0847ec8f in nr_arena_group_update () #8 0x0847cf70 in nr_arena_item_invoke_update () #9 0x0847ec8f in nr_arena_group_update () #10 0x0847cf70 in nr_arena_item_invoke_update () #11 0x0847ec8f in nr_arena_group_update () #12 0x0847cf70 in nr_arena_item_invoke_update () #13 0x0847ec8f in nr_arena_group_update () #14 0x0847cf70 in nr_arena_item_invoke_update () #15 0x084283c2 in sp_icon_doc_icon () #16 0x084291ee in load_svg_pixels () #17 0x084292f9 in prerender_icon () #18 0x08429d24 in icon_prerender_task () #19 0xb7340c91 in ?? () from /usr/lib/libglib-2.0.so.0 #20 0x00000000 in ?? ()
Note the several calls to nr_arena_group_update() and nr_arena_item_invoke_update(). The precise 2geom routines usually vary, but I see these two calls consistently during the slowed down phase.
Hope this helps; it would be nice to have it fixed (I need to start Inkscape pretty often for testing, and this slowdown makes it quite annoying).
Many thanks, Max
[1] I first noticed this by drawing a star and converting it to a path (Shift+Ctrl+C) directly after startup, during which the cursor kept its hourglass state for about 15s. It doesn't seem to be related to path conversion, though.
Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Jun 16, 2008 at 10:27 AM, <J.B.C.Engelen@...1578...> wrote:
I changed bbox calculation to use the 2geom path instead of NArtBpath. I'll do some tests whether this is much slower. Right now I am thinking this is very bad news for my project: it might mean that path transformation (operator*) is significantly slower in the 2geom lib than NR lib...
No need to despair - there was simply no motivation so far to speed up 2geom. Now this motivation is aplenty. I also noticed the slowdowns during work; part of them (during transformations) I traced down to path data writing and reported to Jasper who was looking into it, but part is also undoubtedly blameable on 2geom. So let's make this a call to arms for all 2geom devels to make 0.47 not a bit slower - and ideally faster - than 0.46.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: maandag 16 juni 2008 17:14 To: Engelen, J.B.C. (Johan) Cc: Anhalter42@...173...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Startup slowdown caused by nr_arena_updates?
On Mon, Jun 16, 2008 at 10:27 AM, <J.B.C.Engelen@...1578...> wrote:
I changed bbox calculation to use the 2geom path instead of
NArtBpath.
I'll do some tests whether this is much slower. Right now I am thinking this is very bad news for my project: it might
mean that path
transformation (operator*) is significantly slower in the 2geom lib than NR lib...
No need to despair - there was simply no motivation so far to speed up 2geom. Now this motivation is aplenty. I also noticed the slowdowns during work; part of them (during transformations) I traced down to path data writing and reported to Jasper who was looking into it, but part is also undoubtedly blameable on 2geom. So let's make this a call to arms for all 2geom devels to make 0.47 not a bit slower - and ideally faster - than 0.46.
Thank you for your positive note Bulia!
I was a bit unfair... the "slow" function used to use the rough bbox at first (defined by the handles of the path), instead of the exact bounding box. So I changed that in the code now. Still, operator*(Geom::Path, Geom::Matrix) is a "slow" function, and a lot of time is spent there. So we could try to focus optimizing attempts there.
(I like -pg and gprof for profiling!)
Cheers, Johan
-----Original Message----- From: Engelen, J.B.C. (Johan) Sent: maandag 16 juni 2008 17:45 To: 'bulia byak' Cc: Anhalter42@...173...; inkscape-devel@lists.sourceforge.net Subject: RE: [Inkscape-devel] Startup slowdown caused by nr_arena_updates?
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: maandag 16 juni 2008 17:14 To: Engelen, J.B.C. (Johan) Cc: Anhalter42@...173...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Startup slowdown caused by nr_arena_updates?
On Mon, Jun 16, 2008 at 10:27 AM, <J.B.C.Engelen@...1578...> wrote:
I changed bbox calculation to use the 2geom path instead of
NArtBpath.
I'll do some tests whether this is much slower. Right now I am thinking this is very bad news for my project: it might
mean that path
transformation (operator*) is significantly slower in the
2geom lib
than NR lib...
No need to despair - there was simply no motivation so far
to speed up
2geom. Now this motivation is aplenty. I also noticed the slowdowns during work; part of them (during transformations) I traced down to path data writing and reported to Jasper who was looking into it, but part is also
undoubtedly blameable
on 2geom. So let's make this a call to arms for all 2geom devels to make 0.47 not a bit slower - and ideally faster - than 0.46.
Thank you for your positive note Bulia!
I was a bit unfair... the "slow" function used to use the rough bbox at first (defined by the handles of the path), instead of the exact bounding box. So I changed that in the code now. Still, operator*(Geom::Path, Geom::Matrix) is a "slow" function, and a lot of time is spent there. So we could try to focus optimizing attempts there.
(I like -pg and gprof for profiling!)
The above was false, Inkscape 0.46 *does* use the exact bounding box in that method, so I changed that back. I have refactored the bbox calculation for transformed paths and it is a lot faster now. To conclude I think the huge speed improvement comes from: 1 - no longer generating transformed path, but taking separate points and transforming those 2 - use optimized bbox calculation for straight line segments and cubic segments, instead of the default root finding algorithm.
Now, Inkscape is super fast starting up. Might be worth doing a measurement against Inkscape 0.46, to see how it compares.
Cheers, Johan
(and now I absolutely love -pg and gprof for profiling!)
participants (3)
-
unknown＠example.com -
bulia byak -
Maximilian Albert