[OSM-talk] Profiling the server (was: OGL, OSM, NASA)

Immanuel Scholz immanuel.scholz at gmx.de
Tue Apr 25 14:30:28 BST 2006


>> a) Observation: Predictions are usually wrong
>> b) Conclusion: I predict that you are wrong.  :-D
> well...
> 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)

No offence intended. I am sorry. I did only a rather basic
printf-profiling and even haven't tested any alternative implementation,
so I really have no clue about where performance problems are.

But I won't judge from just setting up a localhost cache which is faster
that it would also be better under the same circumstances the osm server
runs currently (mostly because currently nobody but steve know the exact
circumstances ;)

For JOSM, I can say that the time it takes to import the XML data just
doesn't matter. Its under one second and compared to the very inperformant
internal data storage done by Java its just not relevant. There are other
reasons instead of speed for why I use Java and not, say, python. ;-)

Ciao, Imi.

More information about the talk mailing list