TROSMTileProvider
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
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 <sven@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
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 <thierry.goubier@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 <sven@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
2015-02-05 15:47 GMT+01:00 Sven Van Caekenberghe <sven@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.goubier@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 <sven@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
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 <sven@stfx.eu> 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 <thierry.goubier@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 <sven@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
On 10 Feb 2015, at 12:49, Alexandre Bergel <alexandre.bergel@me.com> 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 <sven@stfx.eu> 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 <thierry.goubier@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 <sven@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
participants (3)
-
Alexandre Bergel -
Sven Van Caekenberghe -
Thierry Goubier