Post Tagged with: "Ruby"

Grape::API¹ is an awesome tool for building APIs in Ruby – it’s quick ² and has a nice DSL with some lovely features. One major issue with it comes whilst developing the application – there is no built in reloading of classes, and whilst there are a couple of threads about implementing reloading³, there’s no progress as yet.

Fortunately, Grape is Rack-based, which allows us to use Shotgun⁴ as a development server, which handles reloading for us. Simply add a

to your Gemfile to give yourself a copy of Shotgun in development mode, run

and then you’ll be able to start your app by running

Visit http://localhost:9393/[your path here], make some changes and refresh to see your changes working, and a major headache gone!

Having been asked by @headius to re-run the previous benchmarks with a single concurrency to get a measure of the raw processing speed of the different VMs. The results are below, and are quite surprising, in my opinion. I have to say I did not expect REE, Ruby Enterprise Edition, to come out on top. Possibly that isn’t too surprising, as it has superior Garbage Collection, compared to MRI. Once again, Rubinius was not as strong as I would have expected, which is leading me to believe that I am not a master of the Rubinius – if anyone knows any ways to force Rubinius to precompile or use something like JRuby’s —server flag, I’d appreciate it!

After my last post, I decided to pit MRI against JRuby to see if there can be any benefits to be gained from going to the JVM. To do this simply, I’ve taken out the Sinatra::Synchrony parts of the app, so this will be a straight Sinatra shootout between the two interpreters. MRI will be represented by 1.9.3p0 and Thin 1.3.1. JRuby will be represented by 1.6.5 and Mizuno. Concurrency 50 It is worth mentioning here that JRuby can go even faster, by some tweaking of the flags when you start the server, but I’ll discuss that at the end. At first glance though, this is a big win for JRuby. Concurrency 100 Again, an apparent big win for JRuby here. Concurrency 250 Once again, JRuby takes the crown here. The Results There is an overwhelming win here for JRuby, but this isn’t exactly as straightforward as the figures look. Read more…

I was curious about how the performance of the new MRI 1.9.3 Interpreter compares to 1.9.2, so I threw together a very quick test application using Sinatra::Synchrony, and tested it under the two Interpreters, as well as Rubinius. I only haven’t tested with JRuby due to the difficulty in getting the fiber aware code for Rack-Fiber-Pool working with something other than WEBrick, and I’m not cruel enough to publish tests using that! I ran the same test at various levels of concurrency, so the following graphs give you what came out. Concurrency 10 Concurrency 20 Concurrency 50 Concurrency 100 Concurrency 250 Well, this is interesting, and what I’d hoped to see – MRI 1.9.3p0 is consistently faster than 1.9.2p290 across the board. It would be a sad day if it wasn’t – let’s face it – we are hoping for progress with each iteration, but good to see. I have Read more…

It might seem obvious, but remember you can inherit from any class when making modular Sinatra apps, so if you find yourself repeating a large amount of functionality, then it is simple to DRY that up. Then just require and inherit from your new class – simple! Obviously not a very complex example, but it’s surprising how often I have to remind myself that simple can still be DRY.