41–50 of 64 posts
Seems like there's obviously a big I/O performance difference. Maybe it's something simple like buffering being setup differently or not at all or sync vs async. It'd be interesting to dig in more Even something like mmap can drastically improve performance since it lets the kernel handle I/O asynchronously from your program execution (so your code doesn't block as much or as easily on I/O)
Here's the summary: Ruby like most of all other Linux applications from that age was written to run in multi-process mode for parallelism, instead of being multi threaded. But running multi-process is heavy on the JVM as it has to load the virtual machine and JIT for every process start, special when the processes are short lived. Java solves it by encouraging running things as multi-threaded instead of multi-process…
This is a valid summary of some facts, but not of the article or facts relevant to the article. Some quotes:
"Jekyll is not forking processes, so that is not the issue."
"The area where JRuby and TruffleRuby shine are long running processes that have had time to warm up. Based on suggestions I put together a repo of a simple small Jekyll build being built 20 times by the same process in a repo here. After 20 builds with the same running process the build times do start to converge, but even after that MRI Ruby is still fastest."
Earlier quoted context omitted.
Could you not make the same argument about JavaScript? JavaScript was pretty slow for many years. Google then put some significant engineering investment into the V8 engine, resulting in a huge increase in JavaScript's performance.
There's significantly more motivation to run JS faster since JS isn't a choice; if you need an interactive website, it will use JS. Ruby is a choice.
Whilst they are doing their multiyear rewrites, it would be nice if someone could optimise the ruby runtime a bit for them.
This process and lack of data in itself sounds like a receipe for performance problems in the JVM version, unless there was some low probabvility coincidence that prevented getting the profile data only in this case. Good measurements are a prerequisite for sustainable and maintainable performance work.
I guess both because CRuby has gotten a lot faster, and because in practice any difference is easily paved over with extra hardware (which is cheap).
So there was no easy way to get a profile from the JVM version, and data came only from looking at the CRuby profiles where file access dominates. Then an informed guess: slower JVM file access. This process and lack of data in itself sounds like a receipe for performance problems in the JVM version, unless there was some low probabvility coincidence that prevented getting the profile data only in this case. Good mea…
Here's the summary: Ruby like most of all other Linux applications from that age was written to run in multi-process mode for parallelism, instead of being multi threaded. But running multi-process is heavy on the JVM as it has to load the virtual machine and JIT for every process start, special when the processes are short lived. Java solves it by encouraging running things as multi-threaded instead of multi-process…
http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0...
If you want fast Ruby it seems Crystal is your only option. Ruby is an interpreted language released in 1996 for scripting. Why are we surprised when attempts to shoe-horn it into something else (Ruby 3.0, JRuby, Truffle Ruby) fall flat?
Ruby's basically as fast as Node.js. If you look at comparative benchmarks, Roda/Rack/Puma is within spitting distance of Koa, Fastify, etc. Express is actually slower in some benchmarks. I don't think a lot of people are aware of just how much faster the Ruby ecosystem has gotten in the past few years (especially when you leave Rails out of the equation which is known not to do well in microbenchmarks).
There's once I was running some jruby stuff in jenkins during a build, the job kept on hanging on some stage, I thought there must be bug somewhere, I forced kill it a couple of times with no success, but kept the last one running before I head home. Then after a couple of hours, I found out an email said the built was passed... eventually, I had figured out that jruby was using /dev/random, since jenkins was running…