immanuel.scholz at gmx.de
Wed Jul 12 12:21:11 BST 2006
> Given that area, it seems to take JOSM about 45-odd seconds on my
> machine to display, of which 25 seconds seems to be waiting for a
> However, a straight api call of
> /map?bbox=-1.40625,51.630859375,-1.0546875,51.796875 seems to take
> about 12 seconds. It's got a fair amount of work to do and I do note
> the status page mentions database performance issues.
*chrm*.. yea.. JOSM is a bit hungry in resources, especally memory ;-)
But there are some patches and improvements already on the way, as example
not updating the byte count that often (whose gain some seconds)..
Of course, with JOSM alone, I cannot get faster than the direct URL access.
> Thinking that it was query-bound, I hacked a quick java equivalent of
> the API, ran the same queries (though I had to substitute
> current_nodes for nodes, etc), and found I could return equivalent xml
> from my creaky old local machine as XML in about 5-6 seconds (5558
> nodes, 6154 segments, 238 Ways)
I've written "little-osm" (in subversion), which uses an optimized version
of the data structure. It is an almost 100% compatible map request and is
quite fast, especally it does not need any markable initial time before
the data transfer starts.
So the next huge performance gain (after Steve's improvement lately) will
come from specialized databases used as caches.
> Is ruby particularly slow at the rowset->xml generation phase?
> Is JOSM doing more work than a simple map call ?
Yes and yes. Ruby still uses REXML here and there which is slow and memory
consuming. Some parts are already translated into libXml, which is a lot
faster. Be welcome, if you want to help hacking on the server code! :-)
And JOSM has to parse in the received XML structure and store it in intern
data format, which can take some seconds, especally on older machines or
ones with low memory. Be sure to use the latest josm when downloading GPX
files - it is a lot friendlier for parsing this than the latest release.
More information about the dev