Huge memory consumption

[dopelover]

Inkscape consumes almost 1,2GB of RAM just after opening an attached file.
It is almost 9 times more than Illustrator consumes while working with the same file.

This problem affects Inkscape 0.48 on Windows XP as well as rev 10022 from trunk build under Ubuntu 10.10.

I have also noticed that memory consumption rises rapidly while Inkscape generates a preview ot the attached file in "Open file" dialog. Additionally, memory is not being freed even if I resign from opening file hitting "Cancel" button.

[su_v (suv-lp)]

> Inkscape consumes almost 1,2GB of RAM just after
> opening an attached file.

Confirmed

> It is almost 9 times more than Illustrator consumes

Compared with Squiggle (batik-1.8pre-2011-01-19): memory consumption increases about 34 MB, the file opens instantly.

> memory consumption rises rapidly while Inkscape
> generates a preview

Confirmed

> memory is not being freed even if I resign from
> opening file hitting "Cancel" button

Not confirmed

Tested with Inkscape 0.48+devel r10025 on OS X 10.5.8
MBP Pro 2.4 GHz Intel C2D, 2 GB RAM)
LeWitt:bug suv$ uname -a
Darwin LeWitt.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
LeWitt:bug suv$ g++ --version
i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)

[su_v (suv-lp)]

correction:
- Tested with Inkscape 0.48+devel r10025 on OS X 10.5.8
+ Tested with Inkscape 0.48+devel r10022 on OS X 10.5.8

[Pablo Trabajos (pajarico)]

Tested and confirmed with r10012 on windows 7. Eventually it opens and displays right but crashes after ungrouping the first group.

[Pablo Trabajos (pajarico)]

My previous report was related to mapy.svgz file. I haven't seen behaviour like this for a while.
Can you tell us little about the origin of the file?

[dopelover (dopelover)]

The file was sent to me as a Corel Draw file. I wanted to convert it
into eps to place it into InDesign project. I don't use Corel Draw so I
decided to convert it using Inkscape.

[Pablo Trabajos (pajarico)]

I understand it was opened with Inkscape using uniconvertor to do the conversion. Maybe attaching the original CDR file is a good idea. If the resulting SVG file it's corrupted it might be a bug in uniconvertor and not in Inkscape.

[su_v (suv-lp)]

> If the resulting SVG file it's corrupted

IMHO not likely, otherwise Squiggle (Batik) would have complained (it is stricter than Inkscape with regard to compliance to the SVG specification and one of Inkscape reference SVG implementations).

[su_v (suv-lp)]

This file reminds me e.g. of bug #425967 (note that on Windows, some memory-related issues have been improved with 0.48 - at least for loading certain files, though not when exporting e.g. SVG files from OpenStreetMap to PNG: see <https://bugs.launchpad.net/inkscape/+bug/168914/comments/11>).

[su_v (suv-lp)]

Attaching a variation of the original file (changes were made externally using a text editor) to allow further investigation: this file opens reasonably fast with the initial zoom setting, and while zooming to page consumes the same amount of memory (~1GB), inkscape seems snappier (at least on my system, see above) than with the four copies of paths on top of each other.

The file structure is highly inefficient BTW - the drop shadow could be created with a single path outlining the (unioned) group of districts, at the moment it uses a copy of each path, slightly offset, regardless of whether it is visible or not.

The changes made to the (externally gunzipped) SVG source (note that none of the actual path data was edited): Main changes are the initial zoom level and zoom center, and the translation of the path groups to no longer lay on top of each other. Also, the viewBox attribute was corrected (if no units are given, it assumes px).

LeWitt:bug suv$ diff 712742-mapy-gunzipped.svg 712742-mapy-gunzipped-groups-moved-aside-3.svg
12,14c12,14
< width="595.276pt"
< height="841.89pt"
< viewBox="0 0 595.276 841.89"
---
> width="1540.00pt"
> height="1200.00pt"
> viewBox="0 0 1925 1500"
45,47c45,47
< inkscape:zoom="0.40337809"
< inkscape:cx="685.48582"
< inkscape:cy="549.41898"
---
> inkscape:zoom="1.25"
> inkscape:cx="465"
> inkscape:cy="1120"
49,50c49,50
< inkscape:window-y="24"
< inkscape:window-maximized="1"
---
> inkscape:window-y="0"
> inkscape:window-maximized="0"
58c58
< <g
---
> <g transform="translate(0,700)"
1947c1947
< <g
---
> <g transform="translate(1000,0)"
1951c1951
< <g
---
> <g transform="translate(0,700)"
LeWitt:bug suv$

[dopelover (dopelover)]

Tjis is an original Corel file.

[Pablo Trabajos (pajarico)]

I opened that file in Corel Draw X5 and did a "save as" to SVG (file attached). It opens correctly in Inkscape 0.48+10012, consuming 600-650 MB, zooming in and out doesn't raise memory use. I exported text as text in Corel options.

dopelover, consider using the trial version of Corel or tell me if you want to have it converted in a different way.

[Pablo Trabajos (pajarico)]

@~suv:
>The file structure is highly inefficient BTW - the drop shadow could be created with a single path outlining the (unioned) group of districts, at the moment it uses a copy of each path, slightly offset, regardless of whether it is visible or not.

That's how the original file looks. Not only there is a shadow for every district, but also some gray names hidden under the topmost districts. Screenshot attached.

[Krzysztof Kosinski (tweenk)]

This appears to be fixed in trunk now. None of the files consumes more than 150 MB and memory use remains fairly stable when zooming. Of course there is a lot room for improvement.

[Travis Ayres (trayres)]

I just had the same problem, but on PDF import.
Inkscape is currently taking up 3.4GB of memory (!) and has slowed to a crawl.