Re: [Inkscape-devel] Re: [Inkscape-user] loading large files
Hi, Thanks very much for looking into this further. I re-emerged inkscape and tried loading the file again but, I'm afraid, gave up after 12 minutes or so.
<snip>
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.
Mine didn't get to the point of swapping, instead (watching top) I see that it rapidly uses up 55.5% or so of memory and then stops using any more (at least until I killed it). What machines you are running on? Mine is a 1700MHz Pentium M, 512Mb ram.
<snip>
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.
w.r.t singly-linked-lists, does Sodipodi store these structures differently? Sodipodi opens this file in about 30 seconds on my machine. However, both sodipodi and my colleague's copy of Adobe, which also loads the file, seem to chop off the image (which is very wide) at its left and right extents - so perhaps they don't really load the whole file.
Perhaps I'm just asking too much & should make my files smaller? Thanks again, gav.
P.S. Incidentally, Adobe has a nice feature - a progress bar while it's loading...
___________________________________________________________
Book yourself something to look forward to in 2005. Cheap flights - http://www.tiscali.co.uk/travel/flights/ Bargain holidays - http://www.tiscali.co.uk/travel/holidays/
Quoting gavinband@...663...:
Mine didn't get to the point of swapping, instead (watching top) I see that it rapidly uses up 55.5% or so of memory and then stops using any more (at least until I killed it). What machines you are running on? Mine is a 1700MHz Pentium M, 512Mb ram.
Mine is a 500MHz Celeron w/ 512MB RAM (n.b. I had some other memory-hungry things running at the time, hence the swapping).
One other difference which would make it take longer for me is was that I was using recent CVS, which uses a virtual function to find the next sibling rather than directly accessing the field as 0.40 does.
That is not normally a performance issue, but for a document like this the loader's abuse of the O(n) sp_repr_append_child() for every individual element multiplies that small extra cost by a very large number. [ it should have built a reversed list of children and then prepended them, as prepending is O(1) ]
I think I am going to commit some code tonight that will also make appending children an O(1) operation, since many people seem to have historically used sp_repr_append_child() without thinking about its cost.
w.r.t singly-linked-lists, does Sodipodi store these structures differently?
Nope. We inherited Sodipodi's data structures.
Sodipodi opens this file in about 30 seconds on my machine.
Hmm.
It would be interesting to run Inkscape from gdb, and press control+C once it hangs, and get a backtrace to see in which code it is hung up. You would want to do a build with debug info stripping turned off in your ebuild options though (I think executable stripping is a default under Gentoo?).
We are probably paying heavily for livarot's inefficiency versus Sodipodi's renderer here as well.
However, both sodipodi and my colleague's copy of Adobe, which also loads the file, seem to chop off the image (which is very wide) at its left and right extents - so perhaps they don't really load the whole file.
That might just be a rendering limitation.
Perhaps I'm just asking too much & should make my files smaller?
Maybe yes, in the short-term. But Inkscape should still be able to handle the image better than it is currently, up to the limits of the machine's resources.
P.S. Incidentally, Adobe has a nice feature - a progress bar while it's loading...
I would like that too. I have some architectural work in mind to make that possible (it would also theoretically enable incremental loading for e.g. image previews in the file dialog). But that will have to wait for a few months I think.
-mental
On Thu, 27 Jan 2005 17:15:53 -0500, mental@...3... <mental@...3...> wrote:
Quoting gavinband@...663...:
Mine didn't get to the point of swapping, instead (watching top) I see that it rapidly uses up 55.5% or so of memory and then stops using any more (at least until I killed it). What machines you are running on? Mine is a 1700MHz Pentium M, 512Mb ram.
Mine is a 500MHz Celeron w/ 512MB RAM (n.b. I had some other memory-hungry things running at the time, hence the swapping).
And mine is Athlon 1200, also 512 MB RAM. But I also have a 2Gb swap partition, which may be the reason.
One other difference which would make it take longer for me is was that I was using recent CVS, which uses a virtual function to find the next sibling rather than directly accessing the field as 0.40 does.
Not likely, I use latest CVS too.
We are probably paying heavily for livarot's inefficiency versus Sodipodi's renderer here as well.
Not likely. Once it loads, it is scrollable and ediable as usual. Slow, but workable.
On Thu, 27 Jan 2005 17:15:53 -0500, mental@...3... <mental@...3...> wrote:
That is not normally a performance issue, but for a document like this the loader's abuse of the O(n) sp_repr_append_child() for every individual element multiplies that small extra cost by a very large number. [ it should have built a reversed list of children and then prepended them, as prepending is O(1) ]
I think I am going to commit some code tonight that will also make appending children an O(1) operation, since many people seem to have historically used sp_repr_append_child() without thinking about its cost.
I think that should help. Here are some interrupts during load, at random moments:
Program received signal SIGINT, Interrupt. [Switching to Thread 1087741248 (LWP 10532)] 0x081d81d4 in Inkscape::XML::SimpleNode::lastChild (this=0x82d71d8) at xml/simple-node.cpp:139 139 child = child->next(); Current language: auto; currently c++ (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x081d81d4 in Inkscape::XML::SimpleNode::lastChild (this=0x82d71d8) at xml/simple-node.cpp:139 139 child = child->next(); (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x081d428d in virtual thunk to Inkscape::XML::SimpleNode::next() () at xml/simple-node.cpp:32 32 SimpleNode::SimpleNode(int code) (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x081d429a in Inkscape::XML::SimpleNode::next (this=0xc28c350) at simple-node.h:57 57 SPRepr *next() { return _next; } (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x08102195 in sp_object_attach_reref (parent=0x8527a48, object=0x994f7a0, next=0x0) at sp-object.cpp:437 437 for ( ref = &parent->children ; *ref ; ref = &(*ref)->next ) { (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x080ce351 in sp_document_get_type () at document.cpp:74 74 { (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x08102195 in sp_object_attach_reref (parent=0x8527a48, object=0xcb15328, next=0x0) at sp-object.cpp:437 437 for ( ref = &parent->children ; *ref ; ref = &(*ref)->next ) { (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x40c7f9e8 in mallopt () from /lib/tls/libc.so.6 (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x08102195 in sp_object_attach_reref (parent=0x8527a48, object=0xe05cac8, next=0x0) at sp-object.cpp:437 437 for ( ref = &parent->children ; *ref ; ref = &(*ref)->next ) { (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x08102195 in sp_object_attach_reref (parent=0x8527a48, object=0xe8f2998, next=0x0) at sp-object.cpp:437 437 for ( ref = &parent->children ; *ref ; ref = &(*ref)->next ) { (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x08102195 in sp_object_attach_reref (parent=0x8527a48, object=0xf2f5528, next=0x0) at sp-object.cpp:437 437 for ( ref = &parent->children ; *ref ; ref = &(*ref)->next ) { (gdb) c Continuing.
Program received signal SIGINT, Interrupt. 0x08102195 in sp_object_attach_reref (parent=0x8527a48, object=0x10304690, next=0x0) at sp-object.cpp:437 437 for ( ref = &parent->children ; *ref ; ref = &(*ref)->next ) { (gdb) c Continuing.
So, most time seems to be spent in sp_object_attach_reref, SimpleNode::next(), SimpleNode::lastChild().
On Thu, 2005-01-27 at 18:54, bulia byak wrote:
So, most time seems to be spent in sp_object_attach_reref, SimpleNode::next(), SimpleNode::lastChild().
Makes sense. The change I have in mind to speed up SimpleNode::appendChild() should also make SimpleNode::lastChild() faster, slashing the number of calls to SimpleNode::next().
-mental
On Thu, 2005-01-27 at 18:54, bulia byak wrote:
Program received signal SIGINT, Interrupt. 0x08102195 in sp_object_attach_reref (parent=0x8527a48, object=0x10304690, next=0x0) at sp-object.cpp:437 437 for ( ref = &parent->children ; *ref ; ref = &(*ref)->next ) { (gdb) c Continuing.
So, most time seems to be spent in sp_object_attach_reref,
Ugh, I just looked at sp_object_attach_reref again. It seems like someone was determined to implement that in the most inefficient way possible...
[ the &(*ref)->next business looks like my work, actually, though I'm pretty sure the interface and algorithm were not original to me, I just never bothered to change them when I rewrote... ]
Sadly I've not yet abstracted SPObject the same way I have SPRepr, so making any changes to SPObject will involve rebuilding pretty much the whole tree. Making attach_reref more efficient will have to wait for another night...
[ I'm going to stop crossposting to the users list with this post, since this is kind of offtopic for there. ]
-mental
participants (3)
-
unknown＠example.com -
bulia byak -
MenTaLguY