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 about them).
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 gets
- 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 nearly 20ms).
- 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
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.