TROSMTileProvider

> On 28 Jan 2015, at 16:58, Thierry Goubier <[hidden email]> 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 <[hidden email]>:
> 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
>
>
>

> Le 5 févr. 2015 à 11:47, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>> 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
>>
>>
>>
>
>

> Alexandre  
>
>
>
>> Le 5 févr. 2015 à 11:47, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>> 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
>>>
>>>
>>>
>>
>>
>