[Tilesathome] less inkscape calls in _unstable

[David Lynch]

On Wed, Sep 24, 2008 at 06:00, Matthias Julius <lists at julius-net.net> wrote:
> "David Lynch" <djlynch at gmail.com> writes:
>
>> My only issue with removing striped rendering is with memory usage.
>>
>> I'm running the stable version and was assigned a very dense tileset
>> earlier in the evening (central Helsinki, complexity over 13 million
>> according to the number returned by the server.) I saved the SVG
>> output to test, and the Inkscape process rendering the full zoom 17
>> image (at 8196x8196) took about 2.5GB of memory, which is a huge
>> amount for something that runs (for me, at least) in the background.
>>
>> Maybe the most complex files should be split up. Rendering one quarter
>> of that file (half the height and half the width) seemed fine.
>
> Did you compare this with the stable client?  How much memory is
> Inkscape using there?

I didn't see as it was running, but I ran two stripes from that file
with approximately the same command as the stable client would have
run (output 8192 wide, 256 high of the full range of x and 1/32 of y)
and they used approximately 400 MB and 700 MB. The quarter image I
mentioned last night was about 900 MB to render.

> The assumption so far is that Inkscape is rendering the whole SVG
> anyway and the cropping it to the part of the image it was asked for.
> If this is true it should consume just as much memory for the striped
> rendering and then do it 32 times.

> Do you know how much memory it used for z16?  A 8196 pixel RGBA image
> should consume 256 MB of memory.  This is only a tenth of the memory
> usage you have seen.  I suspect the memory usage is more dependant on
> the complexity of the SVG than it is on the size of the output image.

I've run Inkscape a few times with that tileset and a couple others and found:
 - When Inkscape starts, there is a substantial amount of time elapsed
and memory allocated before the output file is created. The length of
time and amount of memory used are roughly proportional to the size of
the SVG file, and don't seem to change based on the output parameters.
 - After the output file is created, the amount of memory and time
used varies with the complexity and size of the area being output.
Complexity changes things more than more than size, and memory changes
more than time.

Given those observations, my assumption is that it is loading and
parsing the entire contents of the SVG, but that the rendering isn't
of the full image.

This morning, I got a usage of 1.2 GB on a 4096x4096 render of the z17
data (the only file I kept) and 1.4 GB when re-running the 8192x8192
render. I don't know what accounts for a full gigabyte of difference
from the previous attempt; I'm fairly sure I didn't misread either set
of numbers, but that might be the case.

Overall, eliminating as much of the striped rendering as possible does
seem to be the way to go, given the overhead in starting Inkscape. I'm
playing the devil's advocate somewhat, since the example I happened to
get is probably close to the upper bound for complexity. How to deal
with those sorts of cases falls back on the old programmer's dilemma
of speed versus memory efficiency.

-- 
David J. Lynch
djlynch at gmail.com