I've finally had an opportunity to spend some time analyzing the problem you had loading that large SVG.
Your file did eventually load, although I think it may have taken as much as half an hour to do so on my machine.
In Inkscape, sibling XML nodes are currently kept in singly-linked lists, which are not an efficient data structure when dealing with large numbers of siblings (in this case, more than 87000).
It is possible to use faster data structures, but they would come at the cost of using extra memory. As it was, once the document loaded my machine ran out of memory when the renderer kicked in.
So, I'm not really sure what the best course of action would be. I do think we have a problem dealing with large documents in general.
I am CCing the development list for their suggestions.
-mental
On Wed, 26 Jan 2005 18:01:41 -0500, MenTaLguY <mental@...3...> wrote:
I've finally had an opportunity to spend some time analyzing the problem you had loading that large SVG.
Your file did eventually load, although I think it may have taken as much as half an hour to do so on my machine.
Wow, it was under 2 minutes on mine :) (I'm speaking about 1236745up.svg, is this what you tried?)
So, I'm not really sure what the best course of action would be. I do think we have a problem dealing with large documents in general.
Just FYI, Batik ran out of memory on that document, and Adobe never loaded it either (maybe it would if I waited long enough, but I doubt that). So Inkscape was the only software capable of loading and even editing it.
On Wed, 2005-01-26 at 18:22, bulia byak wrote:
On Wed, 26 Jan 2005 18:01:41 -0500, MenTaLguY <mental@...3...> wrote:
I've finally had an opportunity to spend some time analyzing the problem you had loading that large SVG.
Your file did eventually load, although I think it may have taken as much as half an hour to do so on my machine.
Wow, it was under 2 minutes on mine :) (I'm speaking about 1236745up.svg, is this what you tried?)
Yep. I was also starting to swap a bit towards the end, which may have contributed.
So, I'm not really sure what the best course of action would be. I do think we have a problem dealing with large documents in general.
Just FYI, Batik ran out of memory on that document, and Adobe never loaded it either (maybe it would if I waited long enough, but I doubt that). So Inkscape was the only software capable of loading and even editing it.
Yes, Batik failed for me as well. I didn't have Adobe handy.
-mental
I've comitted the O(1) append fix. Turns out I'd just implemented appendChild() using lastChild(), so it was only lastChild() that I really needed to modify.
Loading does go noticably faster, though it feels like there are still (likely non-Repr-related) bottlenecks we can also address.
[ I must say it's rather nice to finally be able to make changes to the structure of what used to be SPRepr without requiring half the tree to be rebuilt. ]
Please test, as I have tested but I've not been so good at finding broken things lately.
-mental
I think I just succeeded in replicating gavin's hang. It's our old friend the infinite (or at least very long...) loop calling GC_collect_or_expand() repeatedly.
I think perhaps I am going to try an alternate implementation of GC::Anchored.
With a massive document like Gavin's the present implementation is essentially creating several hundred thousand individual GC roots (one gc_malloc_uncollectable()ed shim per object), which might not be such a good thing for the collector.
I am going to CC the libgc mailing list in case Hans wants to reassure me that allocating so many small gc_malloc_uncollectable() objects that all point to nodes in the same large tree is not a problem.
[ note that this is now with the default free space divisor, so we should be using the normal code path ... however, I've not upgraded libgc as 6.3 is still the most recent version available in Debian ]
-mental
On Fri, 28 Jan 2005 00:46:07 -0500, MenTaLguY <mental@...3...> wrote:
I think I just succeeded in replicating gavin's hang. It's our old friend the infinite (or at least very long...) loop calling GC_collect_or_expand() repeatedly.
So, does it still hang with your O(1) fix?
[ note that this is now with the default free space divisor, so we should be using the normal code path ... however, I've not upgraded libgc as 6.3 is still the most recent version available in Debian ]
Ha, I use 6.4, which may be why I didn't see it taking more than 2 minutes. Please compile 6.4 and see if it fixes it for you. This will be an important result if it does.
Just tried CVS with your fix, it does improve the load time but not by much (was 1:50, now 1:39).
On Fri, 2005-01-28 at 01:04, bulia byak wrote:
On Fri, 28 Jan 2005 00:46:07 -0500, MenTaLguY <mental@...3...> wrote:
I think I just succeeded in replicating gavin's hang. It's our old friend the infinite (or at least very long...) loop calling GC_collect_or_expand() repeatedly.
So, does it still hang with your O(1) fix?
Yes, most of the time.
-mental
On Fri, Jan 28, 2005 at 12:46:07AM -0500, MenTaLguY wrote:
[ note that this is now with the default free space divisor, so we should be using the normal code path ... however, I've not upgraded libgc as 6.3 is still the most recent version available in Debian ]
Here, I built 6.4 for debian:
# My stuff!! deb http://www.outflux.net/debian unstable/ deb-src http://www.outflux.net/debian unstable/
Or, directly:
http://outflux.net/debian/unstable/libgc-dev_6.4-1_i386.deb http://outflux.net/debian/unstable/libgc1_6.4-1_i386.deb
I need to figure out how to do a bug report to ask the maintainer to bump up to the next version...
(I'm still recompiling inkscape to see if my hang bug goes away too.)
On Fri, Jan 28, 2005 at 12:46:07AM -0500, MenTaLguY wrote:
[ note that this is now with the default free space divisor, so we should be using the normal code path ... however, I've not upgraded libgc as 6.3 is still the most recent version available in Debian ]
libgc 6.4 (and current inkscape CVS) no longer hangs my giant SVG either! Yay!
On Fri, 28 Jan 2005 14:28:34 -0800, Kees Cook <inkscape@...62...> wrote:
libgc 6.4 (and current inkscape CVS) no longer hangs my giant SVG either! Yay!
Fantastic. Now there are even more reasons to test the Windows freeze bug and make sure it's gone too. Quoting myself:
WIN 1073459 - This one frustrates me. It may be fixed but we can't figure out for sure yet. I asked about it before but got no definitive answer. Those who builds on Windows: Please check which version of libgc (boehm) you are using. If it is 6.4 AND you use latest CVS, see if you can reproduce this bug. If it's not 6.4, ask the person you got it from (Ishmal?) for this version. PLEASE LET'S CLOSE THIS ONE. It alone is worth a release.
Kees, Ishmal, anyone, can you at least tell us which gc version is used by the latest windows builds?
On Fri, Jan 28, 2005 at 07:00:08PM -0400, bulia byak wrote:
Kees, Ishmal, anyone, can you at least tell us which gc version is used by the latest windows builds?
What I've been using for my local windows builds is surely gc 6.3 (the ZIP bundle predates the gc release date). I'm not sure how to crosscompile a new version into the bundle bob creates. I figure it requires some kind of xming32 magic. :)
On Fri, 28 Jan 2005 18:19:58 -0800, Kees Cook <inkscape@...62...> wrote:
On Fri, Jan 28, 2005 at 07:00:08PM -0400, bulia byak wrote:
Kees, Ishmal, anyone, can you at least tell us which gc version is used by the latest windows builds?
What I've been using for my local windows builds is surely gc 6.3 (the ZIP bundle predates the gc release date). I'm not sure how to crosscompile a new version into the bundle bob creates. I figure it requires some kind of xming32 magic. :)
Can you please cooperate with Bob on that? I think Bob already did 6.4 compile for win, but I'm not sure if it's now in his official bundle or not. We absolutely need 6.4 for both Windows build and the static rpm for the release.
On Fri, Jan 28, 2005 at 10:22:13PM -0400, bulia byak wrote:
Can you please cooperate with Bob on that? I think Bob already did 6.4 compile for win, but I'm not sure if it's now in his official bundle or not. We absolutely need 6.4 for both Windows build and the static rpm for the release.
I'll give it a shot. It's for sure be in there for the Linux static build (what with the autoconf changes).
Bob, where'd your Win32 port page go?
http://troi.hous.es3.titan.com/~rjamison/inkscape/
404
I have been fiddling with some large files for a while and usually running into trouble. Today I set up win32 autobuild 0501291707 and tried to get it to load a 2.2MB .png file. Formerly, Inkscape went away and died. Now it actually loads but the graphic was outside the A4 canvas and I had to go to A0 format to see it. By the way, does anyone have any other idea on how to view a graphic which has been saved way off the canvas?
The important thing was that it did load although doing anything was like swimming in cold molasses.
vellum
On Wed, 26 Jan 2005 18:01:41 -0500, MenTaLguY <mental@...3...> wrote:
I've finally had an opportunity to spend some time analyzing the problem you had loading that large SVG.
Your file did eventually load, although I think it may have taken as much as half an hour to do so on my machine.
I can give some gdb backtraces, if you point me to the file you are talking about. I have a problem with Inkscape's memory usage myself -- when I trace large photos which turn to ~ >10 000 nodes large paths. In several cases (e.g. 2 paths with ca. 50 000 nodes each + original bitmap) Inkscape ate up to 1 Gbyte memory and died in pain.
Alexandre
participants (5)
-
Alexandre Prokoudine -
bulia byak -
Kees Cook -
MenTaLguY -
vellum