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 :) C/C++ is not a prototype language. 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 :) >>> the database is currently the bottleneck and i'm pretty sure they >>> already wrote that in C :-) >> The database that is used in production isn't the most efficient one too ;) >> So that is also optimised ;) > > how did you optimise it? (other than converting ways to relations)? Not using MySQL, but MonetDB. It uses column based storage. >> Double: 50~100ms >> Integer: 40~80ms >> >> But the calltrace revealed in both search situation more optimisations where >> possible. > > 20% is pretty significant. obviously thats an optimisation worth having. 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. Stefan _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
