Matt Amos wrote: > On Fri, Nov 21, 2008 at 11:45 AM, Stefan de Konink <[EMAIL PROTECTED]> wrote: >> Matt Amos wrote: >>> "premature optimisation is the root of all evil" ;-) >> A premature optimisation would be starting with integers, C, and more. > > premature optimisation would be writing something in C(++) when it > isn't the bottleneck.
I hear a different thing when I browse on this list about ruby memory usage :) > 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 ;) >> Now >> even I implemented a relatively 'old' API (0.5) and started with doubles ;) >> Last night I introduced a comparison table with the 2^32/360 stuff. To see >> there is 10ms improvement per bbox request ;) > > what was %age gain? i mean, if its a 10ms improvement on a 500ms call > then it might not be such a big deal. if its a 10ms gain on an 11ms > call that would be fantastic. Double: 50~100ms Integer: 40~80ms But the calltrace revealed in both search situation more optimisations where possible. > don't forget that the rails port also handles user management, > friends, messages, diaries, gps points, etc... it would be better to > say you have implemented part of 'old' API 0.5. I have implemented API0.5 + XAPI. User management and GPX was on the todo. If I implement user management I'll implement an OpenStreetProxy, for now I don't even keep changes (for reasons I already mentioned). Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev