Speeding Up Ruby with Shared Strings

https://tenderlovemaking.com/2018/02/12/speeding-up-ruby-with-shared-strings.html

by tenderlove • 8 years ago

194 37 8 years ago

tenderlovemaking.com

heartbreak• 8 years ago

Is it documented anywhere what length of string can be embedded within an RString?

mperham• 8 years ago

24. VALUE is 40 bytes and needs two 8-byte elements.

vidarh2• 8 years ago

Object allocations really are a big deal with Ruby. My Ruby compiler project has been really slow moving again over the last year, but as far as I can tell the current main hurdle is a basic garbage collector, as even adding various object caching, I actually exhaust the 2GB heap (the compiler was started when i386 was a reasonable initial architecture choice...)...

Granted that's worse that it'd be for MRI, as it includes allocating actual objects even for Fixnum and Symbol (MRI uses tagged values for both and just pretend they're "real" objects), though I added caching for both that cut hundred of thousands of allocations..

raitom• 8 years ago

Kinda suprised when I see title like that on HN that not so many people are talking about Crystal https://crystal-lang.org. Basically Ruby with C performances.

So far I’ve been more convinced by Crystal than Elixir as the next language for a Ruby developer.

whalesalad• 8 years ago

Departing the Ruby ecosystem is a dealbreaker in many situations. Crystal is faster but you’re gonna spend more time reinventing the wheel and building common tools that are sitting on the shelf in Ruby land. Not picking a side here, just trying to point out why Ruby is still very popular.

eropple2• 8 years ago

You don't? The joke of the Rust Evangelism Strike Force needs to be updated with the Crystal one, near as I can tell. Nearly every thread where Ruby's discussed has the Crystal Guy (specific identity of any given Crystal Guy up for debate) parachuting in.

Crystal is not the next language for this Ruby developer. Ruby remains it, along with JavaScript when Node makes sense. It often feels like the folks evangelizing Crystal really don't get why people use Ruby--if I need static typing I'm going to go use Kotlin or Rust or C++; looking like Ruby and not having any of the things that make Ruby valuable to me (namely, the features implied by dynamic typing, and to forestall the usual, no, Crystal macros don't replace it) is a demerit, not a positive.

hnzix• 8 years ago

if I need static typing

And that's when the Static Typing Is The One True Way person parachutes in. :)

tomc19852• 8 years ago

Neither are "next languages," all three differ significantly in scope. For the western Ruby dev (meaning Rails people) there is a much clearer and more consistent path forward with Elixir/Phoenix.

pmontra• 8 years ago

After a couple of paid projects with Phoenix I'm not sure it's a path forward. More like a fork in the road to a different destination. I'll steal pattern matching from Elixir and keep using Ruby on Rails. Phoenix adds too much unnecessary complications for the average web app, starting with Ecto. Potentially great when building complex systems, but there are not many of them.

My suggestions are: simple to average web apps, stay with Ruby (Rails) or Python (Django); complex, look into Elixir (Phoenix.)

I never used Crystal so I can't say anything about it.

chrisseaton• 8 years ago

But Crystal is a totally different language. The syntax and some things like the basic object model look similar, but the whole way you use it and the ecosystem are totally separate. I don't think it's 'basically Ruby' at all - I don't think much of the Ruby ecosystem (Rails for example) would translate onto Crystal.

bdcravens• 8 years ago

I assume if all you're building are command-line apps, that might be true. Generally speaking though, I think most Ruby developers are smart enough to move where the market and ecosystem is, and are not constrained by syntax.

pmarreck• 8 years ago

Go to Crystal if you just want to go faster.

Go to Elixir if you actually want to learn more, expand your mind, and are tired of bugs that can only occur in a mutable OOP language. And if you want to take advantage of the extra guarantees provided by a functional language, such as functional immutable datastructures making concurrency idiotproof.

eropple2• 8 years ago

There isn't much that is "mind-expanding" about Elixir coming from Ruby or really any other interesting, dynamically-typed language that I know. It's fine but it's nothing special; BEAM is a better argument for it than Elixir itself.

Maybe rein it in a bit.

dragonwriter• 8 years ago

Kinda suprised when I see title like that on HN that not so many people are talking about Crystal

There is a dedicated contingent promoting Crystal in every thread about Ruby. Don't really know that we need any more (better, perhaps, but not more.)

Basically Ruby with C performances.

Well, vaguely Ruby-ish syntax, without the dynamic features or ecosystem, and with a static type system.

So far I’ve been more convinced by Crystal than Elixir as the next language for a Ruby developer.

Not sure what that has the do with the subject here, which has nothing to do with either Elixir or the next language for a Ruby developer.

Language (or tool) evangelism with no connection to be thread beyond offering an alternative to a language mentioned in the thread is basically a uniquely geeky form of threadcrapping, and its really not any better than any other threadcrapping.

nurettin• 8 years ago

Elixir is a successful experiment. Crystal could have become a success if they decided to have 100% syntactic equivalence. As it is, it requires rewrites in even trivial console scripts.

vidarh2• 8 years ago

This is what baffles me about it. It keeps being touted by some as a "faster Ruby", while they explicitly make decisions that makes it incompatible with Ruby even when it comes to relatively simple syntax.

ExactoKnight• 8 years ago

Crystal is so strict about type coercions, it's actually way harder to use than you realize.

Seriously, try converting over a decently complex script to crystal from ruby, you'll run into complicated problems.

PricelessValue• 8 years ago

So essentially string interning for Ruby?

hyperpape3• 8 years ago

There are significant differences. Depending on the case, it can be more or less effective.

1) If you intern all strings, then you're guaranteed to have one copy of "Hello World", which this doesn't (you could concatenate "Hello" and "World" twice).

2) String interning doesn't let similar strings share the same array. The Ruby trick lets you have

    "Hello World"
    "World"
    "orld"
    "rld"
    "ld"
    "d"

all share the same underlying array, whereas string interning gives you a separate array for each.

rimliu• 8 years ago

I think Substring in Swift is something similar?

smitherfield• 8 years ago

Why couldn't you do both?

hyperpape3• 8 years ago

The optimization of reusing the character array for a string was used in Java until roughly the Java 7 days, when it was dropped because it could cause a space leak: https://stackoverflow.com/questions/15612157/substring-metho....

One difference in Java was that you could slice out the middle of a string (you just kept the start and end of the array, iirc). I wonder if that difference makes this approach workable for Ruby, or if that implies that one team made a mistake.

tenderlove2• 8 years ago

Good question, I'll have to read up on it. It looks like it's possible to share out of the middle of a string with MRI, but it requires certain compiler options that aren't on by default.

Thanks for the comment! <3

igravious• 8 years ago

Does this optimization mean we can dispense with Bootsnap? The magic Bootsnap does makes me fearful and it adds yet another moving part that can break :(

aardvark1792• 8 years ago

It’s not quite that simple. Java strings and ruby strings have quite different semantics because Java strings are immutable whilst Ruby strings are both mutable and can be mutated in place by C extensions. In Truffleruby we use ropes to represent strings which allow sharing of substrings and convert them to unique mutable ropes when they are accessed by C extensions, but that requires quite a lot of machinery to implement.

hyperpape3• 8 years ago

I always forget that about ruby strings.

However, I’m not sure I can think through how it changes the performance trade offs of sharing.

tyingq• 8 years ago

I wonder how Ruby string performance compares to Perl then. They seem to have the same constraints.

banachtarski• 8 years ago

Looks like something that would benefit more from a string_view type abstraction.

mmanfrin2• 8 years ago

Aaron is my personal career idol. I love seeing his work come up on here, it gives me a view in to the deeper workings of ruby that are years beyond my expertise, but in a way that I can mostly grok what's going on. I'm super happy github hired him to hack around on ruby.

Also, his talks are excellent; his closing keynote for RailsConf in particular seems worth recommending, as it was about his work speeding up Rails using kind of similar string optimizations/caching:

https://www.youtube.com/watch?v=BTTygyxuGj8

tenderlove2• 8 years ago

Thank you so much. This really means a lot to me!

mmanfrin2• 8 years ago

You mean a lot to me :] thanks for being a person in the ruby community that we all can aspire to be like.

Speeding Up Ruby with Shared Strings

Related Stories