From: Richard Conroy Date: 2006-09-14T05:10:41+09:00 Subject: Re: Joel Spolsky on languages for web programmingr On 9/13/06, Bira wrote: > As I've said before "For Performance, write it in C" is merely the > thread's title. My bad, knee-jerk reaction. I hope you can understand - between all the responses generated by Joels posts, both in agreement and against, I haven't seen anything along the lines of: "Heres how I did CPU-intensive stuff in my Rails app without resorting to OS executables or C extensions". I expected to see one by now, especially now that Joel has backed it up with realistic examples. > What actually went on in there is that a lot of people > disagreed rather strongly with this proposal and presented several > alternatives that presented satisfactory performance both in Ruby an > in other languages (the Ocaml example comes to mind as being faster > than the C one for a specific test case). I read some of the thread. I missed many of the good counterarguments then. I will drill down then. > When I say that you should read that thread, it's not because I want > to convince you to "write it in C for performance". I don't. I'm just > pointing out that an extensive discussion on Ruby's performance and > what is being done to improve it has already taken place. If it's > something you're really interested in, you should look at it, since it > contains many good messages from both sides of the issue. I guess I am looking for the short form. Ruby/Rails isn't getting anywhere near our project(s) unless I prove the case for it. And I have to do that research in between all the work I am meant to be doing. I guess I will mine that discussion again. I would just like to know whether certain truisms from other languages still hold, like if you are in a pinch, unburden the memory recycler, or consider bitwise operation. Solutions like those might just be enough - go all Yoda on optimisation or something. Down the line, possibly in the lifetime of our project, JRuby might be a fallback plan with which we can preserve platform neutrality. In the meantime I want to see what non-fallback plans I can find, that are more appropriate in a Rails context.