[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