Inkscape 0.91 much slower than 0.48.5 with larger files

[Andrei Nacu]

The latest stable version of Inkscape, 0.91, is much slower than 0.48.5, especially at text typing and moving objects (I see no performance issues with zooming, panning and the rest, zooming and panning is actually faster compared to 0.48.5).

I held an Inkscape workshop in April using 0.91 and most computers running Windows had this issue with slow text typing and slow object move. Those running Linux and Mac worked perfectly.

On the other hand, Inkscape 0.48.5 works fine and I still use it because of these problems with 0.91 (x64 or x86).

I have a 2012 Asus laptop, 64 bit, Intel Core i7, 8GB, and Intel HD3000 graphics. Tested with Windows 8.1 and Windows 10.

Originally I thought this could be related to https://bugs.launchpad.net/inkscape/+bug/1359450 AND https://bugs.launchpad.net/inkscape/+bug/1219794, but in my case CPU usage only rises to about 20%.

[su_v (suv-lp)]

Which installer did you use for Inkscape 0.91 - 32bit or 64bit?

On 2015-08-04 22:58 (+0200), Andrei Nacu wrote:
> (…) and Intel HD3000 graphics.

If you used the 64bit installer - does hiding the rulers help to improve performance? If so, then this report is likely about the known regression with more recent versions of cairo (as included in the 64bit packages of Inkscape for Windows) on systems with Intel graphics card, already tracked in

* Bug #1351597 “Inkscape + Cairo >= 1.12 very slow on Windows, unless rulers are hidden”
  https://bugs.launchpad.net/inkscape/+bug/1351597

[su_v (suv-lp)]

> (…) text typing and moving objects

These are likely separate issues - does the reduced performance when moving objects affect 32bit and 64bit builds equally?

[Andrei Nacu (andreinacu1)]

I tried with both the 32 and 64 bit installers and the 7zip 32/64 bit files.
Hiding the rulers doesn't help.

[Andrei Nacu (andreinacu1)]

Maybe it's also important to say that these issues start to appear once a project reaches about 1.3-1.4 MB in size. It affects the 32 and 64 builds in the same way.

[su_v (suv-lp)]

Any chance you could attach a test case or two (Inkscape SVG files), with 'steps to reproduce' to allow further investigation and tests / comparisons on other platforms (with different versions of Inkscape)?

[Andrei Nacu (andreinacu1)]

A test case is this map created in Inkscape> https://upload.wikimedia.org/wikipedia/commons/f/f4/France_L-2_%281812%29-en.svg

Steps to reproduce/ moving objects:

1. Unlock the LANDS layer
2. Move a polygon

Actual Results:
Object moves very slowly, in steps

Expected Results (in 0.48.5):
Object moves smoothly

Steps to reproduce/ text typing:

1. Unlock the TEXT layer
2. Try to edit some text label
3. Try to add some new text

Actual Results:
Characters will appear in groups of 4-5-6 slowly.

Expected Results (in 0.48.5):
Characters will appear one by one faster.

[su_v (suv-lp)]

1) Poor performance when dragging objects:
AFAICT this is likely a known regression already tracked in
* Bug #1198317 “Dragging objects in compex document very slow in 0.48+devel”
  https://bugs.launchpad.net/inkscape/+bug/1198317

It is triggered by the stroked paths on layers like
- LAKES AND SEA
- RIVERS
- BORDERS
- ADMIN

If all the listed layers are hidden, the performance to drag an object on 'LANDS' in Inkscape 0.91 is as expected. The more of these listed layers are visible, the worse the performance gets when dragging an object with the mouse. Switching to the geometric bounding box mode as mentioned in bug #1198317 also improves performance, even with all layers visible.

2) Poor performance when editing/adding text:
Does not happen when all but layer 'TEXT' is deleted. Possibly related to 1) (to be investigated).

[su_v (suv-lp)]

Addendum: Tests mentioned in comment 7 all done with Inkscape 0.91 r13725 on OS X 10.7.5 (64bit local build).

[su_v (suv-lp)]

Regression with Inkscape 0.91 r13725 compared to Inkscape 0.48.5 r10040 confirmed on OS X 10.7.5 (local 64bit builds), for both aspects:
- poor performance when dragging objects (bug #1198317)
- poor performance when editing/adding text (possibly related: bug #1398032)

Hiding the layers which trigger bug #1198317 does also improve the text editing/adding performance (text editing in 0.91 feels somewhat less "snappier" than with 0.48.5).

[Andrei Nacu (andreinacu1)]

I can confirm changing to geometric bounding box improves the performance when dragging objects.

Text typing performance is also improved, but if you duplicate the TEXT layer twice the typing becomes slow again.

[Andrei Nacu (andreinacu1)]

used Inkscape 0.91, 64-bit version on Windows 10 in comment #10 and just tested with 32-bit now. No difference between 32 and 64-bit versions.

[Cosmin Saveanu (csaveanu)]

This bug is critical. Any hints about how we could investigate its origin further would be much appreciated.

[Cosmin Saveanu (csaveanu)]

Changing to Geometric bounding box did not make any difference in my case. A file with 4000 objects that can be edited fast in 0.48.5, cannot be edited at all in 0.91 on a Mac OS X Yosemite system.

[su_v (suv-lp)]

On 2015-08-28 16:36 (+0200), Cosmin Saveanu wrote:
> Changing to Geometric bounding box did not make any difference in my
> case.

Apparently the issue you experience is not the same as originally reported and tracked here (bug #1481479).

To allow further investigation, please file a separate report, provide information about OS/platform and tested Inkscape builds, attach a test case and describe the steps to reproduce.

[Cosmin Saveanu (csaveanu)]

I'm sorry for not being clear in my comments, but what I see is exactly like the behaviour described in comment #6. The only difference is that in my case the operating system is Mac OS Yosemite 10.10.5. I'm using Inkscape to build figures for scientific manuscripts and a frequent occurence is files that are around 1-2 Mb in size because there are hundreds or thousands of identical objects (dots for a scatterplot, see attached file for a test case). Two versions of Inkscape behave very differently:

0.48.5 r10040 works as expected
0.91 r13725 performance begins to degrade with increasing number of objects in the file. In the end, this version is not usable any more for editing pictures containing scatterplots.

I also tested the last development version 0.91 r14326 custom and it behaves like the stable 0.91.

Slow text adding and editing. Steps to reproduce:

1. Open attached file
2. Try to add new text. First letter appears in about 3 seconds after typing it, and the next appear after a long wait.

The same file opened in 0.48.5 can be edited, with new added text appearing as expected, almost as soon as it is typed.

[su_v (suv-lp)]

@Cosmin - please file a separate report: there are no stroked paths (the elements which trigger the issue reported here) in your example file (there are about 4468 black-filled instances (<use> elements) of the same symbol named 'glyph0-1' which itself has no stroke defined (stroke:none)) . Similar symptoms experienced by users can be triggered by different underlying issues which need to be investigated separately.

[su_v (suv-lp)]

On 2015-09-01 15:57 (+0200), Cosmin Saveanu wrote:
> 2. Try to add new text. First letter appears in about 3 seconds after
> typing it, and the next appear after a long wait.

BTW - can't fully reproduce this with same builds on OS X 10.7 (first typed letter appears sooner than 1 sec, and the next ones almost immediately). The text tool in 0.91 and trunk overall tends to react less 'snappier' though (as mentioned earlier) compared to 0.48.5.

[Cosmin Saveanu (csaveanu)]

Thank you for testing the file. I'm on a MacPro (early 2009) machine, with a relatively modest graphic card, which might explain the difference in the 'wait' time, if your machine is a newer one. I'll add a new bug report after testing this kind of file on a Windows and on a Linux machine, to see if it is dependent on the operating system.

[su_v (suv-lp)]

What I do notice is that the text tool is much slower with Cosmin's test case if the 'Text and Font' dialog has been opened in the current session (closing it e.g. after it was restored from last session on launch doesn't change this - it merely gets hidden).

[Cosmin Saveanu (csaveanu)]

As suggested by @~suv, transformed the comment in a new bug report:
https://bugs.launchpad.net/inkscape/+bug/1491064

[AG (g-ubuntu-2)]

I can confirm this issue in Inkscape 0.91 running on Windows 10 64bit on a NUC5i7RYH. File size is 4.43MB and editing text takes forever. Previous inkscape version works fine.

[Alex (aklammrodt)]

I can confirm since the release of .91 that it is painfully slower than .48 in certain aspects. I work with Inkscape a lot, and typing text and zooming in and out are particularly slow. Another serious gripe is that copy/paste often results in a complete crash (with no save!), but that's for another thread. These issues were tested on 3 different Win7 and 8.1 (all 64bit) machines...

[Will Clayton (w-d-clayton)]

Installed version .91 on Windows 10 to build simple looking diagrams with lots of text and relatively simple imported SVG graphics for icons. The more icons and more text I add, the slower copy/paste, zooming, and text editing/object moving. I've turned off filters, rulers, and run the UI in grayscale, all to no avail. Inkscape now crashes outright on a quad-core i5 processor with 8 gigs of RAM available to it. Sometimes takes several minutes for the (Not Responding) window title notification to go away. The saved Inkscape SVG file is 5 megabytes in size, and the PDF export is 2.

If you run across this bug and are not a registered user of the site you are encouraged to register an account and chime in. This is a real show stopper. I love Inkscape, and it's one of the few GUI based applications that I can really work. If I have to use Visio to draw this map I'm going to shoot myself in the face.

Moreover, I keep reading that this does not affect Mac or Linux users. I have a new machine coming with an i7 processor and will be running Linux on it just to circumvent this problem (I'd rather run Linux anyway TBH). If the problem persists I'll definitely have to move on with my broken heart.

[Will Clayton (w-d-clayton)]

Wanted to add that the processor utilization doesn't seem too high when Inkscape is not responding. When making heavy use of all layers at the same time I see all four cores' utilization spike. With complex layers visible or not Inkscape becomes unusable after a certain amount of time. I really noticed the sluggishness after the saved SVG file grew to about 2 megabytes in size.

[Simone Pisano (sp-simonepisano)]

I am new to inkscape but I am experiencing the same problem.
Everything is quite slow, but moving objects and editing text is actually painful. Again, the bigger the file, the slower it is.
I have also noticed that the processor usage does not go higher than 20%, might it be that the program uses only one core or something like that?
I have tried the same files on illustrator and they run smoothly, and it's a shame because illustrator is a crappy program compared to inkscape.
I have also tried with 0.48.5 and with that is much smoother, especially the text editing. Nevertheless, when trying to move a lot of objects together it becomes stuttery and again the processor never goes higher than 20% usage.
I have windows 10, i7 4710HQ, 8GB ram and a geForce970 gtx.

[Tómas Vignir Gudlaugsson (tvignir)]

Experiencing the same problem on Windows 10 with i5-6600k, 16GB ram, Geforce 560 GTX. Load on all four cores increases but only to around 30%.

[René Becker (limhes)]

Experiencing exactly the same when working on slightly large files (> 1 or 2 MB) containing quite some data. This is extremely annoying, especially since version 0.48 worked perfectly fine. Working on Windows 7 64-bit with Celeron 2957U (1.4 GHz), 16 GB RAM (Asus Vivo).

[Sebastian (sebastian69)]

Same here, Xubuntu 14.04, 16 GB RAM, i7-4700HQ CPU @ 2.40GHz. v0.48 was significantly faster and rarely sluggish. Forced to downgrade. Hulk sad.

Otherwise, wonderful software. Thank you!

[John Goatcher (johnkg)]

I have found the same issue as comment #6.
Adding text can take a couple of seconds per character added!

System is Windows x64 with recent i7 and lots of RAM.
0.48 works fine but these releases exibit the issue; 0.91 x32 or x64 and 0.92 x32 or x64.

My test case is a file about 9 MB in size containing a map with contours.

The issue is clearly proportional to the size of the file since as I shrink it, things speed in proportion until when the contours have all gone and the file is small, it all works well again.

The issue is sufficiently bad that it renders 0.91 and 0.92 unusaable in my case.

[kuro68k (kuro68k)]

Same issue on Windows 8.1 x64, 32GB RAM, Radeon 7970 GPU. I can provide test files if required. Willing to test fixes.

[Stepan Roucka (rouckas)]

I am experiencing the problem on Ubuntu 16.04 and Inkscape 0.91 as well. Text editing is so slow that it makes inkscape unusable.

[MichaelH (michaelh78)]

I started using Inkscape 2 years ago when 0.91 was already released.
Today I tried 0.48 and I was blown away. The difference in performance is night and day.
0.9x is constantly getting unresponsive. 0.91 was running semi ok on windows 7, but after upgrading to win10 it was unusable.

With 0.48 I can actually get things done.
All these newer features and crashfixes aren't worth it if the program in general performs so poor that you want to switch to some (non existing) alternative.

[gerardgerard (gerardgerard)]

Same to me, with Inkspace 0.92 64bits win10, everything freezes, trying to do multiple selection with Alt also freezes, completely unusable. Glad to see this is a bug, I though it just couldn't handle files with a number of objects above certain threshold

[marcel (marcel-tippmann)]

Same reason, we haven´t updated yet from 0.48 to 0.92 (64bits win10). Much much slower than 0.48 especially with large files.

[gerardgerard (gerardgerard)]

Just installed version 0.48, way better. Right now and in my opinion, version 0.92 should be avoided for anyone working with complex images, it is just unusable.

[simonvh (simon-vanheeringen)]

Just tried the snap package for Inkscape 0.92.1 on Ubuntu 16.10. It is completely unusable for me. Due to extreme slowness and freezing I can't edit images that worked fine with 0.48.

[mrtwister (mrtwister)]

For me, this issue (Windows 7) is gone with a fresh install of Inkscape 0.92.1 r15371 32bit.

[John Goatcher (johnkg)]

I just tested the x32 and x64 version of 0.92.1 r15371 on a 64 bit Windows 7 and the isuse remains in both installations for me. My test is simply to type some text which on my large file is very very slow.

[Martin Tompa (tompa)]

I am a newbie to inkscape, but encountered the same problem with version 0.91. I'm running Windows 10 and my svg file was up to 6.7 MB. Editing text, dragging objects, and stretching objects were all painfully, painfully slow. Today I followed the lead of other users and reverted to version 0.48.5 and the performance problems disappeared. Inkscape is once again a pleasure to use, as it had been with version 0.91 when my file was still small.

Note that hiding complex layers or turning off filters or hiding rulers did not make the slightest difference in 0.91's slow performance for me.

[John Franck (jmfranck)]

Just wanted to add that I have the same issue here, and to emphasize the importance of this bug.

In fact, I recently (~3/17) had an issue where I installed Inkscape on a new computer, and it was so slow that I was unable to edit larger files that I had created in previous versions of Inkscape.

I actually had no idea what was going on until I found this very helpful thread -- I reverted to 0.48, and it was like magic!

For very large files (e.g. those used to generate posters for conferences, which can have file sizes in the 100's of MB) this really makes the difference between a great program (0.48) and a completely non-functional (0.91) one.

I've tried turning off filters, layer, rulers, etc, and none of these work.