2015-02-05 15:47 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>: > Thierry, Onil, > > I rounded up my experiments with a 2nd commit on my experimental branch: > > === > Name: Roassal2-SvenVanCaekenberghe.720 > Author: SvenVanCaekenberghe > Time: 5 February 2015, 3:40:43.211681 pm > UUID: 121ffc22-4a30-4153-bef1-e019a92862bc > Ancestors: Roassal2-SvenVanCaekenberghe.719 > > Experimental branch. Second version. > > Some more changes after discussing with Thierry @ Pharo Days and hours of > experimenting > > Added TROSMTileProvider>>#cachedTileNamed: and #memoryCachedTileNamed: > > Rewrote/simplified TROSMShape>>#getTile: to no longer fork a 'get tile' > process when the tile is cached in memory or on the file system > > Removed all hacks trying to optimize the number of times #signalUpdate was > called - made no difference. > > Tried several logging approaches but that did not reveal anything special. > > The observed slowdown for tiles in the file cache but not the memory cache > is still there, even though loading about 10 tiles takes less than 40 ms > (see #testEmptyMemoryCacheParisLevel7) > === > > > Summary, it should be faster, but it is not. Forking and network > downloading are gone, each of about 10 tiles takes less than 4 ms, the > total observed slowdown is still about 1 to 2 seconds - with no extra > #signalUpdate. > > I don't know why and I don't understand. > > I hope somebody can have a look, I feel that we can/should make this > better still. >
Yes, but we don't know yet how :( Thanks Sven for all the work. Thierry > > Sven > > > On 28 Jan 2015, at 16:58, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > > > Hi Sven, > > > > Thanks for the work. I'll have a try (if I manage to get the time) and > we'll meet tomorrow for sure :) > > > > Thierry > > > > 2015-01-28 14:43 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>: > > Hi Thierry, Onil, > > > > First let me iterate what I wrote last week, the OSM stuff in Roassal is > very cool, very well written. Great work. > > > > Since I have some experience with OSM maps, tiles and serving them, I > had a look to see if I could optimise the tile drawing/loading, which is > visibly a bit slow, one would assume because of the loading of the tiles > over the network. > > > > I just committed (based on code that I wrote some time ago): > > > > === > > Name: Roassal2-SvenVanCaekenberghe.719 > > Author: SvenVanCaekenberghe > > Time: 28 January 2015, 2:31:50.462461 pm > > UUID: 0978fb6a-d6d0-4d86-a9ae-1f2f83a0b6a2 > > Ancestors: Roassal2-AlexandreBergel.718 > > > > Experimental branch. > > > > Introduction of TROSMTileProvider to optimize getting OSM tiles, adds > one shared memory cache and a local file system cache, predefines and > reuses 6 http clients spread over different hosts. > > > > Modifies TROSMShape>>#getTile: and adds TROSMShape>>#tileNamed: > > === > > > > The strange thing is though, that I can optimise the loading (as > benchmarked separately), but in most cases (not when they are in the memory > cache, but when they are in the file cache) the drawing still has the same > pauses as before - which I don't understand, at all. But it is a bit hard > to explain. > > > > Anyway, Thierry, I will see you tomorrow and the day thereafter and I > hope I can show you what I mean. > > > > Regards, > > > > Sven > > > > > > > > >
