Quoting gavinband@...418...:
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