Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruby Garbage Collector #16

Open
byhbt opened this issue Aug 27, 2020 · 0 comments
Open

Ruby Garbage Collector #16

byhbt opened this issue Aug 27, 2020 · 0 comments
Labels
Book Book quotes, reading

Comments

@byhbt
Copy link
Owner

byhbt commented Aug 27, 2020

Problem:

Source: Ruby Performance Optimization

What’s the deal with the Ruby GC?
Did our code use too much memory?
Is the Ruby GC too slow?
The answer is a resounding yes to both questions.

High memory consumption is intrinsic to Ruby. It’s a side effect of the language design. “Everything is an object” means that programs need extra memory to represent data as Ruby objects. Also, slow garbage collection is a well-known historical problem with Ruby. Its mark-and-sweep, stop-the-world GC is not only the slowest known garbage collection algorithm. It also has to stop the application for the time GC is running. That’s why our application takes almost a dozen seconds to complete.

List of memory-inefficient operations

  • literal syntaxes
"this is string literal".length

Source: The Ruby Programming Language
Object Lifetime (3.8.2)

An object becomes a candidate for garbage collection when it is unreachable—when there are no remaining references to the object except other unreachable objects.

The fact that Ruby uses garbage collection means that Ruby programs are less susceptible to memory leaks than programs written in languages that require objects and memory to be explicitly deallocated and freed. But garbage collection does not mean that memory leaks are impossible: any code that creates long-lived references to objects that would otherwise be short-lived can be a source of memory leaks.

Consider a hash used as a cache. If the cache is not pruned using some kind of least-recently-used algorithm, then cached objects will remain reachable as long as the hash itself is reachable. If the hash is referenced through a global variable, then it will be reachable as long as the Ruby interpreter is running.

Lessons:

The 80-20 rule of Ruby performance optimization: 80% of performance improvements come from memory optimization, so optimize memory first.

References:

What is GC in Ruby?
https://ruby-doc.org/core-2.4.0/GC.html

Understand the GC Stat
https://www.speedshop.co/2017/03/09/a-guide-to-gc-stat.html

https://www.toptal.com/ruby/hunting-ruby-memory-issues
https://brandur.org/ruby-memory
https://www.monitis.com/blog/20-ruby-performance-tips
https://blog.peterzhu.ca/notes-on-ruby-gc

@byhbt byhbt added the Book Book quotes, reading label Aug 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Book Book quotes, reading
Projects
None yet
Development

No branches or pull requests

1 participant