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

Freeze string literals when not mutated. #20946

Merged
merged 1 commit into from Jul 19, 2015

Conversation

Projects
None yet
3 participants
@schneems
Member

schneems commented Jul 19, 2015

I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called let_it_go. After going through the output and adding .freeze I was able to eliminate the creation of 1,114 string objects on EVERY request to codetriage. How does this impact execution?

To look at memory:

require 'get_process_mem'

mem = GetProcessMem.new
GC.start
GC.disable
1_114.times { " " }
before = mem.mb

after = mem.mb
GC.enable
puts "Diff: #{after - before} mb"

Creating 1,114 string objects results in Diff: 0.03125 mb of RAM allocated on every request. Or 1mb every 32 requests.

To look at raw speed:

require 'benchmark/ips'

number_of_objects_reduced = 1_114

Benchmark.ips do |x|
  x.report("freeze")    { number_of_objects_reduced.times { " ".freeze } }
  x.report("no-freeze") { number_of_objects_reduced.times { " " } }
end

We get the results

Calculating -------------------------------------
              freeze     1.428k i/100ms
           no-freeze   609.000  i/100ms
-------------------------------------------------
              freeze     14.363k (± 8.5%) i/s -     71.400k
           no-freeze      6.084k (± 8.1%) i/s -     30.450k

Now we can do some maths:

ips = 6_226k # iterations / 1 second
call_time_before = 1.0 / ips # seconds per iteration 

ips = 15_254 # iterations / 1 second
call_time_after = 1.0 / ips # seconds per iteration 

diff = call_time_before - call_time_after

number_of_objects_reduced * diff * 100

# => 0.4530373333993266 miliseconds saved per request

So we're shaving off 1 second of execution time for every 220 requests.

Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep.

p.s. If you know of a method call that doesn't modify a string input such as String#gsub please give me a pull request to the appropriate file, or open an issue in LetItGo so we can track and freeze more strings.

Keep those strings Frozen

Freeze string literals when not mutated.
I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution?

To look at memory:

```ruby
require 'get_process_mem'

mem = GetProcessMem.new
GC.start
GC.disable
1_114.times { " " }
before = mem.mb

after = mem.mb
GC.enable
puts "Diff: #{after - before} mb"

```

Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests.

To look at raw speed:

```ruby
require 'benchmark/ips'

number_of_objects_reduced = 1_114

Benchmark.ips do |x|
  x.report("freeze")    { number_of_objects_reduced.times { " ".freeze } }
  x.report("no-freeze") { number_of_objects_reduced.times { " " } }
end
```

We get the results

```
Calculating -------------------------------------
              freeze     1.428k i/100ms
           no-freeze   609.000  i/100ms
-------------------------------------------------
              freeze     14.363k (± 8.5%) i/s -     71.400k
           no-freeze      6.084k (± 8.1%) i/s -     30.450k
```

Now we can do some maths:

```ruby
ips = 6_226k # iterations / 1 second
call_time_before = 1.0 / ips # seconds per iteration 

ips = 15_254 # iterations / 1 second
call_time_after = 1.0 / ips # seconds per iteration 

diff = call_time_before - call_time_after

number_of_objects_reduced * diff * 100

# => 0.4530373333993266 miliseconds saved per request
```

So we're shaving off 1 second of execution time for every 220 requests. 

Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep. 

p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37) please [give me a pull request to the appropriate file](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37), or open an issue in LetItGo so we can track and freeze more strings. 

Keep those strings Frozen

![](https://www.dropbox.com/s/z4dj9fdsv213r4v/let-it-go.gif?dl=1)

sgrif added a commit that referenced this pull request Jul 19, 2015

Merge pull request #20946 from schneems/schneems/let-it-go
Freeze string literals when not mutated.

@sgrif sgrif merged commit f91439d into rails:master Jul 19, 2015

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Jul 23, 2015

Member

Wanted to mention that I did the above math wrong. Since each "iteration" of the test created 1_114 objects. So the actual time saved would be what I reported divided by 1_114.

Also the Ram test I did, returns the same result even if you remove the string allocation lines. Benchmarking is hard.

Over a really really long time, it will have an impact, although a small one. Since the change is so straightforward, i'm comfortable with even modest gains here.

Member

schneems commented Jul 23, 2015

Wanted to mention that I did the above math wrong. Since each "iteration" of the test created 1_114 objects. So the actual time saved would be what I reported divided by 1_114.

Also the Ram test I did, returns the same result even if you remove the string allocation lines. Benchmarking is hard.

Over a really really long time, it will have an impact, although a small one. Since the change is so straightforward, i'm comfortable with even modest gains here.

@maximeg

This comment has been minimized.

Show comment
Hide comment
@maximeg

maximeg Jul 26, 2015

Caution, you added a space in the string

Caution, you added a space in the string

This comment has been minimized.

Show comment
Hide comment
@maximeg

maximeg Jul 26, 2015

Ah, that was caught by the specs after the merge, and fixed.

Ah, that was caught by the specs after the merge, and fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment