Posted by Rick DeNatale Fri, 20 Jul 2007 02:49:00 GMT
Charlie Savage just posted a long article about how he reduced the rendering time on his rails app by an order of magnitude.
The article is full of advice on what to do and not to do in coding rails apps. The important message though is the approach to performance tuning by profiling.
Posted by Rick DeNatale Fri, 22 Jun 2007 14:29:00 GMT
Recently on gluttonous, Kevin Clark announced that Powerset is going to launch their front-end on Ruby. It seems that they were already pre-disposed to a major ruby comitment having built a sizable Ruby talent pool for their internal applications.Prior to making the final decision to go all out with ruby for their front-end launch, the did some due diligence which included investigating the facts behind the recent furore caused by an interview with one of Twitter’s developers.
So they went to Twitter’s lead developer, Blaine Cook to get the straight dope.
Quoting Kevin:
The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and at that point you have to rethink your approach. In an email he writes:For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January
That last sounds quite true and corresponds to my experiences in the past with Smalltalk. I used to tell IBM customers that almost all performance comes not from the language but from application design, and that using a dynamic language which allowed the application to be developed in what’s now called an agile development process allows major performance gains through refining, refactoring, and retuning the system as both business and performance requirements get uncovered/discovered.
That’s as least as true of Ruby as it was of Smalltalk 15-20 years ago.
Posted by Rick DeNatale Fri, 22 Dec 2006 17:19:00 GMT
Hmmmmm
I’ve been thinking a bit about the ramifications of the C++ vs. Python vs. Ruby benchmarking fud I wrote about in an earlier post
I’ve been looking at this from the point of view of how Ruby implements Arrays, digging deeply in to array.c, but I just stepped back and I noticed something which might or might not be important.
Besides using an Array rather than a linked list, the Baus Ruby benchmark doesn’t even do the same thing as the C++ one. In C++ the list is being used as a stack, items are added to the head of the list and removed from the head.
In the case of the Ruby benchmark, elements are inserted at the front of the Array using insert(0, obj), but removed using pop, which actually removes the last element. So instead of a stack we have a queue.
The Python code has a variation on the same problem, it uses append which adds to the end of the list, but del(0) which removes the first element.
Now I know that in benchmarking only performance matters, so I guess the old adage Make it work right before you make it work fast doesn’t necessarily apply.
Read more...Posted by Rick DeNatale Tue, 10 Oct 2006 16:43:00 GMT
The topic of defining a new ruby class which could have instances that, like false and nil were seen as a boolean which was not true, just came up on ruby-talk.
This has come up before, and it turns out that in Ruby being untrue is reserved to these two specific instances.
The boolean test is pretty deeply engrained into the implementation of ruby. The actual test seems to be defined in the RTEST macro in ruby.h#define Qnil ((VALUE)4)
#define RTEST(v) (((VALUE)(v) & ~Qnil) != 0)Which means that any object whose reference VALUE has any bit set other than the 3rd LSB is true.
In ruby, the control flow statements like ‘if’ aren’t messages, but are ‘compiled’ into a direct test and conditional branch.
Even Smalltalk, which defined even if/then/else as a message, e.g. booleanValue ifTrue:[Transcript show:'true'] ifFalse: [Transcript show:'false']Posted by Rick DeNatale Tue, 26 Sep 2006 19:17:00 GMT
I've been meaning to write about Ruby performance for a while, and a recent blog post by an old friend and colleague, got me off my proverbial.
The old friend is John Duimovich, who wrote about the relative performance of C++ and Smalltalk and what that could mean for ruby.
John's message is important for those who bemoan the performance of Ruby, and I plan to expand on that message in this and later posts to this blog, but first a few words about Mr. Duimovich.
Read more...I'm an old Smalltalker to whom Ruby looks like an old friend. To get a perspective on my perspective and credentials, have a look at my mini-memoirs
If you like my blog, you might consider recommending me on Working With Rails.
|
|
 |
|
|
|
 |
|
|
