6 ms·

Twitter, Ruby on Rails, Scala and people who don’t RTFA

85 points by mileszs 18y ago

pc 18y ago
This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. The last two statements don't mean the first is true. Ruby's power is not the reason it's slow. Smalltalk VMs are proof by existence that the Ruby model can be fast. (See: Self, Strongtalk, Gemstone.) MagLev showed that Ruby is basically just an alternative Smalltalk syntax. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. "Remove much of Ruby's power"? Around 0.2% of Charles's speed-up came from removing the ability to override the primitive math operations. Other than that, his speedups removed none of Ruby's power. (And nit-picking: Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages. It can do this because any class or object can be extended, any method overridden, any constant undefined and redefined, and so on, and so forth. Not true: >> class StrangeArray < Array; def [](x); x; end; end nil a = StrangeArray.new(10) => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] >> a.map{|x| x} => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] # wrong >> (0..(a.size - 1)).map{|x| a[x]} => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] # right I.e., the built-in implementation of Array#map statically refers to the built-in implementation of Array#[].) (Edited to correct example, as pointed out by hjdivad)
- zitterbewegung 18y ago
  Also pretty much any lisp with some type of syntactic macro system.
- hjdivad 18y ago
  I'm not sure, but I think your counterexample is meant to show you can't replace `Array#pop`. However, that's not what you show -- you show that irb depends on `Array#pop` for its normal usage. Consider: $ ruby -e "class Array; def pop; self.first; end; end; puts [1,2,3].pop" 1
  - deleted 18y ago
    [deleted]
- stcredzero 18y ago
  This power does not come without a price. Ruby is slow. ARRRRGH! Why do the expectations of guys from the 80s and early 90s still rule us? There are Lisp and Smalltalk VMs out there that are something like 70X as fast as Ruby 1.8! If you add Traits (library for Mixins) to Smalltalk, it is equivalent to Ruby in power. (1) The one of the biggest misconceptions we have to face in the Computer programming and related professions, is that programmers are on the forefront of technology. Actually, culture lags technology. And in that, I specifically include the culture of computer programmers. The foundations of OO languages like Ruby and Python were set forth in the 70s and 80s. WYSYWIG word processing, ethernet LANs, desktop publishing existed then in pretty much their current forms at Xerox PARC, only slower. The concepts embodied in Dot-NET and Microsoft's Singularity were bandied about in the 60s, 70s, and 80s. The sad thing about our profession is, is that to learn what's coming next, and what's possible you still have to do some digging into history. Things have improved, but because programming is also a cultural artifact, it lags technology like any other cultural artifact. I keep posting this. I used to wonder why it seemed like tilting at windmills. After writing this post, I now realize why. Alan Kay: "The Computer Revolution Hasn't Happened Yet." http://video.google.com/videoplay?docid=-2950949730059754521 http://video.google.com/videoplay?docid=-2950949730059754521 (1) - In fact, it is homomorphically equivalent. This is precisely why something like Maglev can work. Another interesting thing -- many Lisps are also homomorphically equivalent to at least 90% of the languages out there. And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort.
  - jhancock 18y ago
    thanks for saving me the time. my thoughts exactly! History should be the first thing we teach new programmers.
  - sho 18y ago
    There are NOT SmallTalk libraries out there that are 70x faster than Ruby - that would be faster than raw C (Ruby is about 30x slower). Are you trying to say that SmallTalk is faster on average than raw C? So why isn't everything written in SmallTalk? And I'll believe Maglev's outlandish performance claims if and when I ever see them realised. If they are anything like those claimed at RailsConf 2008 (50x or thereabouts), I'll eat my hat and any other hats anyone cares to send me. I say this as someone who would probably seriously consider murder if it would make my Rails apps run 10x faster. I want it to be true. I just don't think it is, unfortunately. And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort. I keep hearing things like this, but no-one ever does it.
- deleted 18y ago
  [deleted]
deleted 18y ago
[deleted]
wheels 18y ago
I think one thing especially for people coming to web development from other angles in programming is getting used to the fact that you have to know so many technologies / languages to get the job done. In the early days of web apps, you could mostly get by with Perl, SQL, HTML and a little bit of Javascript for mouseovers and whatnot. Framework? CGI.pm, baby. Now you generally need HTML, CSS, Javascript, a Javascript framework, a backend language of choice, a framework of choice in that language, a high-performance backend language of choice for the critical bits, and SQL. I did web apps from 1997 to 2001 and then picked back up in early 2008. It was pretty dizzying at first just knowing where to start. In the systems / multimedia world where I lived in the 7 years between it was C or C++ and a framework. So what's the connection to the story? I think it's in the web world, perhaps as a result of its relative infancy, we apparently have to get used to the fact that the right solution to a problem is often using mixed-mode programming where individual tools are selected for individual tasks -- that development abilities in the web world is as much a question of breadth as depth. We shouldn't be so disenfranchised that our tools aren't general purpose.
- jballanc 18y ago
  I'd take this one step further to point out that web programming is a different beast from desktop programing in that you are attempting to tie a fault-tolerant, low-bandwidth channel (the internet) to a strict, high-bandwidth channel (the CPU/RAM). Add to that impedance mismatches from latency, and I think anyone who expects to have a full stack written using only one language is kidding themselves!
- FooBarWidget 18y ago
  Disagree. You don't need frameworks. You can still use CGI.pm if you want to. But doing so will make your web app look and behave like a 1998 dinosaur, and using a framework is just so much easier, more comfortable and less error-prone. While frameworks add complexity as far as the computer is concerned, they remove complexity as far as the human developer is concerned. I can write a web app in Ruby on Rails much faster than I could ever have with mod_perl, and the result is better-looking and easier to maintain.
Tichy 18y ago
Yes, Ruby is OK - buuut: I would like a language that is good for everything. I don't really understand the argument that "Ruby was only replaced for stuff it wasn't appropriate for". Some languages are good for everything, so why make the effort to learn languages that can not do everything? Yes, there is the DSL stuff, but atm I am not sure if I really care so much for it. For example, yesterday I caused an infinite loop in my Rails controller because I forgot the "@" in front of a variable that had the same name as the action - so Ruby interpreted it as a method call, not a variable reference. Being able to call methods without "()" is part of the Ruby-DSL stuff, but I wonder if typing "()" would not actually be the lesser pain in the end. I probably lose much more time to hunting such bugs than I lose time typing ().
- cosmo7 18y ago
  Well Scala does that () thing too. On the other hand, an infinite loop in Scala would run much more quickly than in Ruby.
  - jorgeortiz85 18y ago
    In Scala, defining a method and a variable with the same name would be a compile-time error.
    - carbon8 18y ago
      A situation like the OP's would run in an infinite loop even in Scala. There's no compile-time error in Scala when you have a method call itself, which is what the OP is describing, and his variable also wasn't named the same as the method: "@name" vs "name".
- davidw 18y ago
  > I would like a language that is good for everything. And how about a pony while you are at it?;-) No language does everything, what you want to aim for is one that does as broad a range of things as possible: http://journal.dedasys.com/2009/03/26/scalable-programming-languages http://journal.dedasys.com/2009/03/26/scalable-programming-l... I think Ruby is 'pretty good' in those terms. Better than Java, IMO, because it lets me do small/quick things easily, something I've always found unpleasant in Java.
mrduncan 18y ago
Ruby is generally recognized as being twice as slow as Python Am I the only one who has never heard of this? I'd definitely be curious to see some relevant benchmarks if anyone has any.
- wheels 18y ago
  It varies naturally per application. When I was doing a little prototyping before deciding to write the core of our ranking algorithm in C++ I took the tightest inner loop and compared C++, Java, Python, Ruby and Perl. For floating point numerics and lots of list traversal the results were: - C++ | baseline - Java | 2.5x baseline - Perl | 4.5x baseline - Python | 6x baseline - Ruby | 14x baseline As a result, we're using C++ where it really matters, Java where it kind of matters and Ruby where it doesn't. This was more than a year ago though, so any performance gains since then naturally aren't included.
- jshen 18y ago
  ruby 1.8 is slower than python, but ruby 1.9 should be on par with it.
jimbokun 18y ago
This linked article: http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht... is really outstanding. It shows you exactly why a language like Ruby is inherently slower than a language like Java. Mainly, because Ruby does a lot more work to give you the cool, dynamic capabilities that make people like Ruby in the first place. Of course, much of the cool work on speeding up dynamic languages like Javascript and Ruby is all about analyzing code to find places where you can safely make assumptions about the code (+ is not overridden here, so I can use the built in integer addition operator, etc.). (I probably oversimplified that, but I hope it captures the general idea.) The "Duby" language at the end makes me think of Common Lisp and how you can optionally declare types the compiler can use to compile faster code. Would it be worthwhile to add optional typing to Ruby?
Hexstream 18y ago
Ok, that was painful to read by moments. "Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages." If Ruby has anything over Lisp in the DSL domain (besides popularity), I'd love to know. "A web development platform as powerful and syntactically concise as Rails could only have been done in Ruby." Idem. "This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. If anything, it shows us skeptics that there is no such thing as a free lunch." Lisp has all (?) the crazy features you love so much about Ruby and more, yet it's very fast (try SBCL, it compiles to native x86).
- beza1e1 18y ago
  Ruby has an advantage over Lisp: syntax Many programmers like syntax, since coding AST-style can be tedious sometimes. Sure, you can create your own reader macro with Lisp, but that is harder than overriding some methods in Ruby. Rails is an example that opinionated software has an edge sometimes and Ruby compared to Lisp is opinionated in terms of syntax.
  - Hexstream 18y ago
    I don't see how the fact many programmers like syntax makes it better. I also don't see how "coding AST-style" can be tedious, especially since it's so much easier to automate the process with macros. Granted, you'll want an editor with support for s-expressions.
    - rimantas 18y ago
      The same way why ease of use of something makes that something better (or more pleasant to work with).
  - joe_the_user 18y ago
longint 18y ago
I really liked this article, and remember reading the original article and thinking that it does a good job of explaining an engineering approach that invariably needs the ability to skillfully use many technologies.
jpedrosa 18y ago
To take the article in the right light, consider that in Ruby-land, syntax is important, it matters. For example, optional parentheses. Spaces are mostly disregarded unless they aren't in a few cases. Switches that support almost any type, even though when folks play with entire Hashes as keys things can fail to work even more during the 1.8 to 1.9 transition... Multiple ways to create literal strings so you can save escaping things inside of them or save some other action. Closures with one block shortcut per method so you can save a little more characters there. These things encourage the developer to revisit their implementations and cut the redundancies much more. The p method coupled with the inspect feature that gives you the description of a certain object so you can debug it or at least see its content very easily. No use comparing Ruby to LISP and Smalltalk in some "power subjectivity"... Ruby is hackish and used by "hackers" alike. It's not perfect of course... And I liked this article for it put into better words what I wrote in some comments on the original article.
grandalf 18y ago
uh I was using Starlng in production and switched to Kestrel expecting a massive speedup. It actually slowed down the queue by about a factor of 10. Maybe the jvm offers GC benefits on massive hardware, but I have not been pleased at all so far.
- fhars 18y ago
  Just to make sure you are measuring the right thing: You made your measurements after passing a few hundred thousand messages through the system to give the JIT in the JVM enough information to act upon? And using a server VM? With which GC? Benchmarks on the JVM are notoriously tricky...
  - grandalf 18y ago
    I put tens of thousands of messages through it before noticing it was slow. And yes, using a server vm (sun's latest)... I haven't given up on it... just posted the above comment b/c I had assumed that Kestrel would just be way faster b/c it's java, which turned out to be quite an erroneous assumption.
MaysonL 18y ago
Languages are neither slow nor fast, only implementations are.

85 points by mileszs 18y ago

pc 18y ago

This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. The last two statements don't mean the first is true. Ruby's power is not the reason it's slow. Smalltalk VMs are proof by existence that the Ruby model can be fast. (See: Self, Strongtalk, Gemstone.) MagLev showed that Ruby is basically just an alternative Smalltalk syntax. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. "Remove much of Ruby's power"? Around 0.2% of Charles's speed-up came from removing the ability to override the primitive math operations. Other than that, his speedups removed none of Ruby's power. (And nit-picking: Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages. It can do this because any class or object can be extended, any method overridden, any constant undefined and redefined, and so on, and so forth. Not true: >> class StrangeArray < Array; def [](x); x; end; end nil a = StrangeArray.new(10) => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] >> a.map{|x| x} => [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil] # wrong >> (0..(a.size - 1)).map{|x| a[x]} => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] # right I.e., the built-in implementation of Array#map statically refers to the built-in implementation of Array#[].) (Edited to correct example, as pointed out by hjdivad)

zitterbewegung 18y ago
Also pretty much any lisp with some type of syntactic macro system.
hjdivad 18y ago
I'm not sure, but I think your counterexample is meant to show you can't replace `Array#pop`. However, that's not what you show -- you show that irb depends on `Array#pop` for its normal usage. Consider: $ ruby -e "class Array; def pop; self.first; end; end; puts [1,2,3].pop" 1
- deleted 18y ago
  [deleted]
stcredzero 18y ago
This power does not come without a price. Ruby is slow. ARRRRGH! Why do the expectations of guys from the 80s and early 90s still rule us? There are Lisp and Smalltalk VMs out there that are something like 70X as fast as Ruby 1.8! If you add Traits (library for Mixins) to Smalltalk, it is equivalent to Ruby in power. (1) The one of the biggest misconceptions we have to face in the Computer programming and related professions, is that programmers are on the forefront of technology. Actually, culture lags technology. And in that, I specifically include the culture of computer programmers. The foundations of OO languages like Ruby and Python were set forth in the 70s and 80s. WYSYWIG word processing, ethernet LANs, desktop publishing existed then in pretty much their current forms at Xerox PARC, only slower. The concepts embodied in Dot-NET and Microsoft's Singularity were bandied about in the 60s, 70s, and 80s. The sad thing about our profession is, is that to learn what's coming next, and what's possible you still have to do some digging into history. Things have improved, but because programming is also a cultural artifact, it lags technology like any other cultural artifact. I keep posting this. I used to wonder why it seemed like tilting at windmills. After writing this post, I now realize why. Alan Kay: "The Computer Revolution Hasn't Happened Yet." http://video.google.com/videoplay?docid=-2950949730059754521 http://video.google.com/videoplay?docid=-2950949730059754521 (1) - In fact, it is homomorphically equivalent. This is precisely why something like Maglev can work. Another interesting thing -- many Lisps are also homomorphically equivalent to at least 90% of the languages out there. And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort.
- jhancock 18y ago
  thanks for saving me the time. my thoughts exactly! History should be the first thing we teach new programmers.
- sho 18y ago
  There are NOT SmallTalk libraries out there that are 70x faster than Ruby - that would be faster than raw C (Ruby is about 30x slower). Are you trying to say that SmallTalk is faster on average than raw C? So why isn't everything written in SmallTalk? And I'll believe Maglev's outlandish performance claims if and when I ever see them realised. If they are anything like those claimed at RailsConf 2008 (50x or thereabouts), I'll eat my hat and any other hats anyone cares to send me. I say this as someone who would probably seriously consider murder if it would make my Rails apps run 10x faster. I want it to be true. I just don't think it is, unfortunately. And one could probably take just about any Lisp and give it the power of the other 10% (like Erlang) with moderate effort. I keep hearing things like this, but no-one ever does it.
deleted 18y ago
[deleted]

deleted 18y ago

[deleted]

wheels 18y ago

I think one thing especially for people coming to web development from other angles in programming is getting used to the fact that you have to know so many technologies / languages to get the job done. In the early days of web apps, you could mostly get by with Perl, SQL, HTML and a little bit of Javascript for mouseovers and whatnot. Framework? CGI.pm, baby. Now you generally need HTML, CSS, Javascript, a Javascript framework, a backend language of choice, a framework of choice in that language, a high-performance backend language of choice for the critical bits, and SQL. I did web apps from 1997 to 2001 and then picked back up in early 2008. It was pretty dizzying at first just knowing where to start. In the systems / multimedia world where I lived in the 7 years between it was C or C++ and a framework. So what's the connection to the story? I think it's in the web world, perhaps as a result of its relative infancy, we apparently have to get used to the fact that the right solution to a problem is often using mixed-mode programming where individual tools are selected for individual tasks -- that development abilities in the web world is as much a question of breadth as depth. We shouldn't be so disenfranchised that our tools aren't general purpose.

jballanc 18y ago
I'd take this one step further to point out that web programming is a different beast from desktop programing in that you are attempting to tie a fault-tolerant, low-bandwidth channel (the internet) to a strict, high-bandwidth channel (the CPU/RAM). Add to that impedance mismatches from latency, and I think anyone who expects to have a full stack written using only one language is kidding themselves!
FooBarWidget 18y ago
Disagree. You don't need frameworks. You can still use CGI.pm if you want to. But doing so will make your web app look and behave like a 1998 dinosaur, and using a framework is just so much easier, more comfortable and less error-prone. While frameworks add complexity as far as the computer is concerned, they remove complexity as far as the human developer is concerned. I can write a web app in Ruby on Rails much faster than I could ever have with mod_perl, and the result is better-looking and easier to maintain.

Tichy 18y ago

Yes, Ruby is OK - buuut: I would like a language that is good for everything. I don't really understand the argument that "Ruby was only replaced for stuff it wasn't appropriate for". Some languages are good for everything, so why make the effort to learn languages that can not do everything? Yes, there is the DSL stuff, but atm I am not sure if I really care so much for it. For example, yesterday I caused an infinite loop in my Rails controller because I forgot the "@" in front of a variable that had the same name as the action - so Ruby interpreted it as a method call, not a variable reference. Being able to call methods without "()" is part of the Ruby-DSL stuff, but I wonder if typing "()" would not actually be the lesser pain in the end. I probably lose much more time to hunting such bugs than I lose time typing ().

cosmo7 18y ago
Well Scala does that () thing too. On the other hand, an infinite loop in Scala would run much more quickly than in Ruby.
- jorgeortiz85 18y ago
  In Scala, defining a method and a variable with the same name would be a compile-time error.
  - carbon8 18y ago
    A situation like the OP's would run in an infinite loop even in Scala. There's no compile-time error in Scala when you have a method call itself, which is what the OP is describing, and his variable also wasn't named the same as the method: "@name" vs "name".
davidw 18y ago
> I would like a language that is good for everything. And how about a pony while you are at it?;-) No language does everything, what you want to aim for is one that does as broad a range of things as possible: http://journal.dedasys.com/2009/03/26/scalable-programming-languages http://journal.dedasys.com/2009/03/26/scalable-programming-l... I think Ruby is 'pretty good' in those terms. Better than Java, IMO, because it lets me do small/quick things easily, something I've always found unpleasant in Java.

mrduncan 18y ago

Ruby is generally recognized as being twice as slow as Python Am I the only one who has never heard of this? I'd definitely be curious to see some relevant benchmarks if anyone has any.

wheels 18y ago
It varies naturally per application. When I was doing a little prototyping before deciding to write the core of our ranking algorithm in C++ I took the tightest inner loop and compared C++, Java, Python, Ruby and Perl. For floating point numerics and lots of list traversal the results were: - C++ | baseline - Java | 2.5x baseline - Perl | 4.5x baseline - Python | 6x baseline - Ruby | 14x baseline As a result, we're using C++ where it really matters, Java where it kind of matters and Ruby where it doesn't. This was more than a year ago though, so any performance gains since then naturally aren't included.
jshen 18y ago
ruby 1.8 is slower than python, but ruby 1.9 should be on par with it.

jimbokun 18y ago

This linked article: http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht... is really outstanding. It shows you exactly why a language like Ruby is inherently slower than a language like Java. Mainly, because Ruby does a lot more work to give you the cool, dynamic capabilities that make people like Ruby in the first place. Of course, much of the cool work on speeding up dynamic languages like Javascript and Ruby is all about analyzing code to find places where you can safely make assumptions about the code (+ is not overridden here, so I can use the built in integer addition operator, etc.). (I probably oversimplified that, but I hope it captures the general idea.) The "Duby" language at the end makes me think of Common Lisp and how you can optionally declare types the compiler can use to compile faster code. Would it be worthwhile to add optional typing to Ruby?

Hexstream 18y ago

Ok, that was painful to read by moments. "Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages." If Ruby has anything over Lisp in the DSL domain (besides popularity), I'd love to know. "A web development platform as powerful and syntactically concise as Rails could only have been done in Ruby." Idem. "This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. If anything, it shows us skeptics that there is no such thing as a free lunch." Lisp has all (?) the crazy features you love so much about Ruby and more, yet it's very fast (try SBCL, it compiles to native x86).

beza1e1 18y ago
Ruby has an advantage over Lisp: syntax Many programmers like syntax, since coding AST-style can be tedious sometimes. Sure, you can create your own reader macro with Lisp, but that is harder than overriding some methods in Ruby. Rails is an example that opinionated software has an edge sometimes and Ruby compared to Lisp is opinionated in terms of syntax.
- Hexstream 18y ago
  I don't see how the fact many programmers like syntax makes it better. I also don't see how "coding AST-style" can be tedious, especially since it's so much easier to automate the process with macros. Granted, you'll want an editor with support for s-expressions.
  - rimantas 18y ago
    The same way why ease of use of something makes that something better (or more pleasant to work with).
- joe_the_user 18y ago

longint 18y ago

I really liked this article, and remember reading the original article and thinking that it does a good job of explaining an engineering approach that invariably needs the ability to skillfully use many technologies.

jpedrosa 18y ago

To take the article in the right light, consider that in Ruby-land, syntax is important, it matters. For example, optional parentheses. Spaces are mostly disregarded unless they aren't in a few cases. Switches that support almost any type, even though when folks play with entire Hashes as keys things can fail to work even more during the 1.8 to 1.9 transition... Multiple ways to create literal strings so you can save escaping things inside of them or save some other action. Closures with one block shortcut per method so you can save a little more characters there. These things encourage the developer to revisit their implementations and cut the redundancies much more. The p method coupled with the inspect feature that gives you the description of a certain object so you can debug it or at least see its content very easily. No use comparing Ruby to LISP and Smalltalk in some "power subjectivity"... Ruby is hackish and used by "hackers" alike. It's not perfect of course... And I liked this article for it put into better words what I wrote in some comments on the original article.

grandalf 18y ago

uh I was using Starlng in production and switched to Kestrel expecting a massive speedup. It actually slowed down the queue by about a factor of 10. Maybe the jvm offers GC benefits on massive hardware, but I have not been pleased at all so far.

fhars 18y ago
Just to make sure you are measuring the right thing: You made your measurements after passing a few hundred thousand messages through the system to give the JIT in the JVM enough information to act upon? And using a server VM? With which GC? Benchmarks on the JVM are notoriously tricky...
- grandalf 18y ago
  I put tens of thousands of messages through it before noticing it was slow. And yes, using a server vm (sun's latest)... I haven't given up on it... just posted the above comment b/c I had assumed that Kestrel would just be way faster b/c it's java, which turned out to be quite an erroneous assumption.

MaysonL 18y ago

Languages are neither slow nor fast, only implementations are.