> On 10 Feb 2015, at 12:49, Alexandre Bergel <[email protected]> wrote: > > Hi Sven!! > > I will check this in two days. I am still on holidays :)
You should include the 14th in your holiday as well unless you refuse to give in to commercial pressure ;-) > 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 >>> >>> >>> >> >> >
