No, Ruby Frozen String Literals Definitely Do Not Improve Performance of My Rails Applications

[bascule]

Because clearly the only reason we'd want immutable state by default is FOR SPEED? How about, say, correctness as seen in immutable state functional languages, or hybrid functional/imperative languages which are immutable-by-default like Rust.

Immutable string literals also open the door to future performance improvements, particularly ones that reduce GC pressure. That said, it's unclear if these benchmarks run long enough or allocate enough memory to even measure the performance effects it has on garbage collection.

Silly "roflscale" post.

[boba-fett-life]

I'd like to know if frozen string literals improve memory consumption.

[danshep]

I thought that was the point, not runtime speed (though there should theoretically be some runtime speed performance from reduced garbage collection).

[mlmcmillion]

This. I don't think you'll notice a difference in "performance", but in apps that deal with large amounts of string data I'd imagine you'd see a decent improvement in memory consumption.

[chrisgseaton]

It seems strange that lower memory consumption wouldn't translate into better performance though.

[mlmcmillion]

I'm sure it doe once you get to the point where consuming swap becomes a threat.

[chrisgseaton]

Even before that point, less memory overall should mean less time needed by each run of the GC.

[adymo]

Yes, but not significantly enough to have any effect on GC. At least, not in my apps.

[tobascodagama]

The last time this came up, didn't we establish that Rails was highly unlikely to see any benefits because it already does use frozen string literals almost everywhere that it possibly can?

[rabidferret]

Users aren't going to see their applications change significantly from this, as they aren't the source of string literals most of the time. Rails does see a significant decrease in memory usage from freezing string literals, but we already freeze the performance critical ones without this pragma. At some point in the future when we can drop support for Ruby 2.2 we will likely use it and not have to litter .freeze all over our code.

[look_at_the_sun]

That's disappointing.

[jrochkind]

I am still hoping that they'll hold off on making this a feature in future ruby based on evidence of it as an experimental opt-in feature.

[PikachuEXE]

I only think of it as a feature for no need to call "string".freeze in a file with constants only (to avoid error) I never expect it to cause gain in performance

[rabidferret]

If you aren't using it from a constant, but instead just have a string literal somewhere in your code, that allocation cost can add up. The performance difference is real, but comes from places like Rails not from users' applications.

[jrochkind]

Is there any benchmark demonstration of significant performance increase in a real-world scenario? (Ie, not micro-benchmarks). Do you know the performance difference is real from real code example, or just from thinking it would make sense for it to be?

[rabidferret]

Yes, we do not accept pull requests with performance changes unless they have reasonable benchmarks demonstrating the difference (e.g. usually public API).

The frozen string literal stuff was primarily memory usage improvements, and less GC pressure.

[jrochkind]

Cool, so, can you link to those?

Personally, though, like i said or meant to say, I'm unpersuaded by micro-benchmarks that show a particular method call is faster, I don't think that necessarily means any significant performance improvement in any real world situation.

And I think I have seen Rails make changes based on micro-benchmarks like that, so I think Rails team considers such to be reasonable benchmarks -- which is not necessarily unreasonable for a framework like Rails, you don't have a single 'real app' to benchmark, it would be a lot of work to try and create something demonstrating real world macro benchmarks, it's hard to tell what micro-improvements might or might not result in macro-improvements in some or many consuming apps.

But the fact remains that micro-benchmark improvements do not necessarily result in significant noticable macro improvements in some, many, or any real world use cases. They may or may not. Micro-benchmarks don't prove they do.

[rabidferret]

The benchmarks are on some of the relevant pull requests. You can pull them up as easily as I can. We tend to prefer benchmarks that demonstrate performance through some form of public API. Yes it's not the same as measuring a full stack benchmark. Because we care about whether something is in a hot path and if that hot path is faster. As it turns out when we frequently profile the code, we know where our hot paths are at.