[OSM-dev] Lean and mean Tile- and XML-API-Server

[Matt Amos]

On Fri, Nov 21, 2008 at 2:22 PM, Stefan de Konink <stefan at konink.de> wrote:
> Matt Amos wrote:
>> ah well, thats the price you pay for being able to easily write code
>> without having to manage memory manually (or stick shared_ptr<> all
>> over the place). there is a bug in there too, i think, which results
>> in libxml not fully free()ing all the memory it is using.
>
> Come on you can give better arguments than that :)

but i don't need to :-)

> C/C++ is not a prototype language.

do you mean http://en.wikipedia.org/wiki/Prototype-based_programming ?

> You will need to have your functional diagrams ready before start
> 'scripting'. So I don't mind pointers, and in this case my webserver's api
> takes care of the string management, so I am a happy coder :)

i don't mind pointers either, but i know a lot of people who do. C++
is a powerful and complex language, which takes a long time to learn
to use properly. in an open-source project, this means either
potential contributors are excluded, or that they submit
poorly-written code. of course, its possible for any developer to make
a mistake, but at least in ruby it is less likely to cause a colossal
failure.

>> how did you optimise it? (other than converting ways to relations)?
>
> Not using MySQL, but MonetDB. It uses column based storage.

interesting. the web site describes it as an in-memory database, but i
assume it can store to disk as well. so why is everyone still using
mysql / postgres / oracle?

> Jup, but extra mathematical overhead in query generation that should not be
> forgotten. Every output has to be atoi -> double back. And in the case of
> storing doubles/floats the input can directly be passed to the user. I need
> to figure out if the overhead of data translation is not bigger than
> querying speed.

to be fair, the latency between here and the states is about 150ms, so
you may not need to optimise further.

cheers,

matt