Hi Sven!! I will check this in two days. I am still on holidays :)
Alexandre > Le 5 févr. 2015 à 11:47, Sven Van Caekenberghe <[email protected]> a écrit : > > 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. > > Sven > >> On 28 Jan 2015, at 16:58, Thierry Goubier <[email protected]> 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 <[email protected]>: >> 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 >> >> >> > >
