[OSM-dev] Ruby developers in Amsterdam

[Matt Amos]

On Tue, Jan 13, 2009 at 1:07 PM, Frederik Ramm <frederik at remote.org> wrote:
> Matt Amos wrote:
>>
>> what do you see as the benefits of an old-fashioned compiled language
>> (presumably you mean C/C++/Java) over just plain ruby? just because
>> we're using ruby doesn't mean we have to use rails+activerecord :-)
>
> I think nothing beats C/C++ (not so sure about Java) when it comes to
> pumping bytes from one source to one destination with as little memory usage
> and as little copying of data as possible.

any java fan would tell you that java is much better nowadays at that
sort of thing. but i'm not a java fan, so i'm going to agree with you
- when memory management really matters, nothing beats doing it
manually.

> I also think that we're at least
> partially operating in areas where it really makes a difference what kind of
> read or write operation you use, how many bytes you send in one buffer, how
> many you request from the database driver, and so on. (And the optimum
> performance settings may well be different for a MySQL and a PostGIS
> backend, so I tend to say "no thank you" if anyone wants to sell me a super
> duper database wrapper that makes everything database "agnostic".)

in which case we're trading development effort for performance. i
think we're operating in areas constrained by the lack of available
developers, so making the barrier to entry higher is a tough decision.
in the short term, i think its the wrong one.

> In 99.9% of applications nobody gives a damn whether some dynamic
> programming language allocates the same memory three times in a row and
> copies the same data from one location to the next, to the next - it's over
> in microseconds and nobody notices, and you're better off writing
> worse-performing better-looking code than squeezing the last juice out of
> your CPU.

and ruby will be getting faster and better with the new VM and GC in
1.9. rails is (allegedly) getting faster with each release. if we're
prepared to stick it out for a while, we may see improved performance
for little effort on our part. also, the front end is one place where
we can use multiple machines to spread the cost of dynamic languages
and gain some redundancy as well.

but we've had continuing problems with high memory usage which may not
be fixed, so there are arguments both ways. i think tomh and firefishy
definitely care about ruby/rails' memory usage :-)

> OSM might be one of the 0.1%. But I might also be wrong.

you identified a real problem - part of OSM is ideally suited to rails
and part of it isn't. assuming that we're talking about after 0.6 -
what should we be doing? is the inclusion of OAuth the right point to
start separating out the different parts of the OSM codebase?

cheers,

matt