Hello everyone,

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 stack.

Recording the startup of Inkscape just until before the Window shows up[1] results in the attached results[2]. The original file is an SVG file (Note: This is a large interactive SVG and primarily intended to be opened in a browser[3]). 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 [4]). 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 responsive.

- 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 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.

Best regards, octycs

[1] I did this by calling exit just before `InkscapeApplication::window_open` returns. [2] 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. [3] Direct link: https://octycs.eu/static/shared/190608_perf_startup_999hz.svg [4] https://gitlab.com/inkscape/inkscape/issues/9#note_132218218