[OSM-talk] Something Might be Broken
Tom Hughes
tom at compton.nu
Sat Aug 1 10:09:12 BST 2009
On 01/08/09 01:08, Andrew Ayre wrote:
>> How exactly is that supposed to help? Will this API have access to
>> some magic accelerator technology that the current API doesn't use?
>
> It would help because people could upload large data sets as fast as
> they can prepare them, then tweak any problems quickly and efficiently.
I understand why a faster API helps. What I don't understand is why you
think there is some magic switch we can flip that would instantly make
it faster - if such a switch existed we would already have flipped it!
> I was perhaps thinking of a dedicated machine/bandwidth for large
> uploads. But then I don't know what the bottleneck is in the current
> system. Is it users, bandwidth, processing power, something else or a
> combination?
I suspect the limitation is primarily how fast you can do all the
processing of the changeset and the required database queries and having
a different client machine won't make the slightest difference to that.
You might be able to get some speedup in the XML parsing but not much
more than that I suspect.
The real way to speed it up (in so far as is possible given the
constraints of the database queries that need to be run) is to rewrite
the API in a more efficient language, which would benefit everybody
rather than a select elite. There has been some work done towards such a
rewrite, but only for the map call so far.
> A couple of weeks ago JOSM told me it would take 15 hours to upload a
> 5Mb OSM file. It seems a bit better recently though.
That number must be plucked out of thin air though - there is no
reasonable way that JOSM can know how long it will take. I've never seen
a changeset take anywhere near that long to apply though.
Tom
--
Tom Hughes (tom at compton.nu)
http://www.compton.nu/
More information about the talk
mailing list