[OSM-talk] OGL, OSM, NASA
sxpert at esitcom.org
Tue Apr 25 13:56:43 BST 2006
Immanuel Scholz wrote:
>>>What part is slow?
>>guess he wasn't using libxml2's sax interface :D
> Yea.. my ruby script uses REXML (its sooooo easy ;-). and so it is slow.
> But hey, you know, you don't HAVE to sit before you computer watching him
> all the time executing a script, right? ;-))))
that's correct, I'd better have it do the thing in a second so I can go
back doing something productive :D
>>I'll attribute the slowness to
>>1) insane SQL queries ( see
>>http://trac.openstreetmap.org/browser/ruby/api/wms/streets.pl#L52 for a
>>2) not using a geometric-aware database engine (1 stems partly from this)
>>3) from 2, not using proper indexes on the things that matter most,
>>specifically indexes that would greatly accelerate requests looking for
>>stuff that is within a 2D box
> a) Observation: Predictions are usually wrong
> b) Conclusion: I predict that you are wrong. :-D
a) observation: I have done my homework prior to writing this mail.
b) conclusion: my working code is visible... go for it, point your josm
to my osm api server, and attempt to download a map
(that's where you'll notice that the java xml implementation you're
using sucks :D... to get a proof of that, do "time wget <blah>" ...)
no, scratch that, lemme do it for you (this is from my work machine,
over the dsl link)
sxpert at raph-dell ~ $ time wget
Resolving www.navsys.org... 18.104.22.168
Connecting to www.navsys.org|22.214.171.124|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
] 924,206 98.71K/s
14:55:46 (72.24 KB/s) -
> No, fun aside. I made the very same assumption, then did a bit of
> benchmarking and found me completly wrong. This had such a surprising
> impact on me, that I did not tried to ever made any other predition about
> the current server code... ;-)
> Ciao, Imi.
More information about the talk