1. 45
  1. 13

    Recently updated a client’s code base from ruby 2.0 -> ruby 2.3 (can’t update to 2.4 because its a rails 3 application. oof) and the speed gains were pretty nuts to be honest. Load times reduced significantly while taking less resources. I can’t wait until we get budget to upgrade it to rails 4+ and a new ruby version as well. The speed-ups will probably be insane.

    I’m super excited to try out ruby 3 with the pattern matching syntax and RActors!

    1. 1

      It was an audacious goal, especially for a language released in 1995.

      Is it just the baggage that’s implied? Or that newer things are necessarily better/faster?

      1. 25

        Maybe the implication is that the language has already been incrementally improving for 25 years, so a 3x speed-up at this point in its development would be quite remarkable.

        1. 4

          The last time I looked at Ruby, it was significantly slower than Squeak, which at the time was a fairly faithful reimplementation of a Blue Book Smalltalk-80 bytecode interpreter and what I’d consider to be minimal baseline performance for a new dynamic language implementation that learned anything from prior work. I believe Squeak has since added JITs and other more modern features but at the time it was focused aggressively on being easy to understand and hack on at the expense of performance. Being slower than Smalltalk when your language is Smalltalk minus several of the bits of Smalltalk that are hardest to implement efficiently was pretty depressing.

          There was definitely a lot of room for improvement.

          1. 3

            I think it’s worth pointing out that Ruby is a much larger language with a huge core library. Surface area matters a lot when it comes to optimizing language performance. A typical Ruby application will touch a lot of language features, so if any part is left unoptimized, that loss may easily dwarf the gains made in other areas. You have to optimize the whole enchilada, and that can be cost-prohibitive for teams without deep pockets.

            I can’t find the links now, but I recall one of the people on PyPy saying Python is harder to optimize than JS just because Python’s core lib surface area is so large. Mike Pall said something similar about why LuaJIT was feasible as a mainly single-person project: the language and libs are tiny.

        2. 1

          Maybe they are saying older things are faster because they were designed for slower computers, making it hard improve on performance?