On 04/01/2012 03:06, alvinpenner wrote:
thanks for the suggestions, I've made the call to Path::Coalesce optional. committed to rev 10835.
Initial tests with debug and optimized builds (both X11 and Quartz based) on two systems - Mac OS X 10.5.8, 32bit, 2.4 GHz Intel Core 2 Duo, 4GB RAM (upgraded) - OS X 10.7.2, 64bit, 2.4 GHz Intel Core i5, 8GB RAM show greatly improved performance when editing files with moderately complex stroked paths ('share/examples/l-systems.svgz' it a good test file IMHO: compare moving one of the generated paths - by dragging it with the mouse - in r10834 and r10835).
Debug builds (-g -O0) still noticeably lag compared to optimized builds (-O3), and the difference of performance between the two laptops (32bit vs 64bit ?) is quite big. But overall trunk is now much closer to the performance of current stable (if using an optimized build).
Many thanks @all for addressing this (r10835)!
I do want to ask about another (possibly related) performance issue which has been bothering me in trunk builds for quite some time and is still present in r10835 (note: performance of the same operations in stable 0.48.2 is ok and fast compared to trunk).
--> Spike of memory usage when zooming in closely in a plain document with lots of dashed stroked lines (e.g. a floor plan) (no filter effects, patterns, markers, etc. involved)
Please download the SVG file from http://commons.wikimedia.org/wiki/File:Zitouna_Mosque_plan.svg 1) open it in current trunk build of inkscape 2) enlarge the document window 3) zoom in repeatedly (to get below 100%)
At some point after changing the zoom levels a lot, Inkscape's memory usage explodes and it grabs whatever it can get (causes paging even with 8GB RAM), and it takes a long time until the window finally gets updated.
The memory (> 2.6 GB) is released immediately when opening a new window and closing the one with the mosque plan zoomed in (i.e. keeping the same inkscape process running, with a new, empty document).
I have this drastic performance loss when zooming in with such a sample file even when using optimized 64bit builds and 8GB RAM - on my older 32bit system, Inkscape usually stops responding, and I have to force-quit it (happens even after upgrading RAM from 2GB to 4GB).
If I edit the file and modify all objects (remove strokes or convert them to path, add fill as needed for tests), performance with zoom operations is ok -> this makes me think it is related to what is discussed in this thread. Possibly due to the many _dashed_ stroked lines?
Can anyone on linux/windows reproduce this?
~suv