10 Feb
2015
10 Feb
'15
12:52 p.m.
On 10 Feb 2015, at 12:49, Alexandre Bergel
<alexandre.bergel(a)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(a)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(a)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(a)stfx.eu>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