On 7 July 2013 14:31, Jon Nordby <[email protected]> wrote: > > I am attaching the callgraps (from tests/test_performance.py -c 1 -s TEST) > here. > layerpaint_zoomed_out_5x: http://i.imgur.com/OZcBjXG.png > brushengine_paint_hires: http://i.imgur.com/qj1o5vO.png > paint_zoomed_out_5x: http://i.imgur.com/e13IKV4.png > > As you can see there are three problem spots: > 1. computing dirty mipmaps > 2. marking tiles as dirty > 3. time spent in get_tile_numpy itself > > 1) is something that we could improve through multi-threading, like we do > with tiles while painting. > This requires that we batch up the tiles to be processed and hand it over > to C++, as one cannot call into Python from multiple threads concurrently. > I attempted to do that, but due to added complexity on Python side, it > turned out slower. > http://gitorious.org/~jonnor/mypaint/jonnors-clone/commits/mipmap-cpp > Alternative approaches to this would be appreciated. > I seem to be close to an algoritm which does this with no temporary datastructure for the mipmap tile graph, so maybe it will work out after all.
> 2) Could maybe be improved by changing mark_mipmap_dirty to not be > recursive, but instead just iterate over the list of mipmap surfaces and > doing surface.tiledict[(tx, ty)] = mipmap_dirty_tile, on each? > Hmm, or maybe we can return early in some cases. If a tile is the > mipmap_dirty_tile, then sure all of the tiles above it will also be > already, so no need to redo it? *goes to tests* > Yup, helped a bit, up to 10%. http://gitorious.org/mypaint/mypaint/commit/e27c3c01f0967b2708e4994dc9b81c35766f2270 > 3) Perhaps avoding recursion could help here to? Apart from that I don't > have many ideas... > I found a place where I could optimize a bit, up to 10% gain. http://gitorious.org/mypaint/mypaint/commit/15d58498a5ee08c8ace6866455c472f5405e1860 -- Jon Nordby - www.jonnor.com
_______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
