While I'm an Inkscape user for some years now, I'm fairly new to it from
a developer point of view.
In terms of performance, I've been recently doing some analysis with the
help of cpu profiling tools.
My aim in this mail is to present some of the things I noticed and maybe
some ideas how to improve them.
The tools I've been using are the gperftools and more recently the linux
performance tool `perf` together with FlameGraphs (Disclaimer: Since
I've been using them for the first time I don't have a deep knowledge
Both tools can capture the stack at a timed interval, so it is possible
to estimate how much time is spent in different functions. These can be
visualized for example by a flame graph which I found quite handy. In
theses graphs the x-axis shows the stack records alphabetically sorted
(not chronologically) and if possible merged. The y-axis shows the call
Recording the startup of Inkscape just until before the Window shows
up results in the attached results. The original file is an SVG
file (Note: This is a large interactive SVG and primarily intended to be
opened in a browser). By looking at the result I identified some
parts that might be of interest (See annotated PNG file).
- A - (100ms):
Based on some individual function calls (e.g. get_preferred_width) I
assume this is related to the layout calculations. Noteworthy is here
that the stack mostly has a depth of up to 80-90 frames. I don't know
whether this is usual for gtk, but for me this looks like the
calculation of the layout might get very complex. Maybe it is possible
in some places to simplify the layout (I'm referring e.g. to ). While
this part only takes around 100ms in this record, the actual impact
could be larger because the recording stops just before the window shows
up. However, even after it shows there is a noticeable delay until it
- B - (170ms):
This part is the setup of the toolboxes at the top. I find interesting
here that with the exception of the TextToolbar, each Toolbar only takes
5-10ms to load, but because there are so many of them, they sum up over
100ms (again without the TextToolbar).
One idea I'll therefore try to look into in the next time is whether it
is possible to lazy-load them, so that the GUI relevant initialization
only runs as soon as required (when the tool is used the first time).
Since most toolbars initialize in up to 10ms the delay is insignificant
when clicking on a tool.
- C and D - (65ms / 80ms):
These relate to the initialization of the menu resp. the DesktopWidget.
I haven't had a much closer look yet, but both take longer than I
assumed. There might be some optimizations possible as well (e.g. I
noticed SwatchesPanel::_rebuild is called at least twice, each running
- E - (260ms):
The last section is about loading the extensions. I don't know a lot
about the extensions system now and the future plans, but I also
wouldn't have expected this part to take that much time.
- Looking further -
The attached recording of the startup here is of course only a part of
interesting parts for optimization (And there are also a lot of parts
that I cannot identify with certainty).
One second aspect I want to look more into is for example the fill and
stroke dialog, which takes up to 600ms to load (not part of the attached
profiling) because all marker images are expensively loaded and rendered
as SPObjects at runtime. And if it is open on startup this time adds up
to the delay before the window even shows up.
All in all I admit that this a rather chaotic collection of maybe or
maybe not promising parts for performance optimizations. This surely
only touches the surface of possible analysis and improvements, but I
wanted to share this early because maybe you have some ideas as well (or
there were some things done in the past that I don't know of).
If you have any feedback I'd appreciate it a lot.
 I did this by calling exit just before
 The results still have parts that are marked as "[unknown]". I tried
solving this by passing "-fno-omit-frame-pointer" (see FlameGraph
documentation for more), but this did not have an effect. Though this
could also be because cmake automatically re-ran when I started building.
 Direct link: