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

Move digest path calculation out of loop #33821

Merged
merged 1 commit into from Sep 11, 2018

Conversation

Projects
None yet
5 participants
@schneems
Member

schneems commented Sep 8, 2018

On every iteration of generating a cache for a collection a “digest path” is calculated even though it’s exactly the same for every element.

This PR exposes a method digest_path_from_virtual that returns back a “digest_path”. This can, in turn, be passed back into cache_fragment_name. This not only does less work but it also (you guessed it) uses less memory.

before: Total allocated: 762539 bytes (7035 objects)
after: Total allocated: 743590 bytes (6621 objects)

(762539 - 743590)/ 762539.0 # => 2.4% faster ⚡️⚡️

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Sep 11, 2018

Member

Fixed my weird rebase issue.

Member

schneems commented Sep 11, 2018

Fixed my weird rebase issue.

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Sep 11, 2018

Member

Updated based on comments

Member

schneems commented Sep 11, 2018

Updated based on comments

Move digest path calculation out of loop
On every iteration of generating a cache for a collection a “digest path” is calculated even though it’s exactly the same for every element.

This PR exposes a method `digest_path_from_virtual` that returns back a “digest_path”. This can in turn be passed back into `cache_fragment_name`. This not only does less work, but it also (you guessed it) uses  less memory.

before: Total allocated: 762539 bytes (7035 objects)
after: Total allocated: 743590 bytes (6621 objects) 


(762539 - 743590)/ 762539.0 # => 2.4% faster ⚡️⚡️

@schneems schneems merged commit 9e24603 into rails:master Sep 11, 2018

2 checks passed

codeclimate All good!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@sriedel

This comment has been minimized.

Show comment
Hide comment
@sriedel

sriedel Sep 19, 2018

I'm confused about the presented statistic: Total allocation for after is larger than for before - so wouldn't it use more memory despite allocating less objects?

Also, how do you get a speed increase from multiplying and dividing bytes allocated? They way I'm reading it, it isn't 2.4% faster - it's allocating 2.4% more memory.

What am I missing?

sriedel commented Sep 19, 2018

I'm confused about the presented statistic: Total allocation for after is larger than for before - so wouldn't it use more memory despite allocating less objects?

Also, how do you get a speed increase from multiplying and dividing bytes allocated? They way I'm reading it, it isn't 2.4% faster - it's allocating 2.4% more memory.

What am I missing?

@tomca32

This comment has been minimized.

Show comment
Hide comment
@tomca32

tomca32 Sep 20, 2018

Are the before and after memory stats flipped in the PR description? The way it's presented it seems that it's using more memory after the change

before: Total allocated: 743590 bytes (7035 objects)
after: Total allocated: 762539 bytes (6621 objects)

after is larger than before

tomca32 commented Sep 20, 2018

Are the before and after memory stats flipped in the PR description? The way it's presented it seems that it's using more memory after the change

before: Total allocated: 743590 bytes (7035 objects)
after: Total allocated: 762539 bytes (6621 objects)

after is larger than before

@schneems

This comment has been minimized.

Show comment
Hide comment
@schneems

schneems Sep 20, 2018

Member

Correct I flipped the bytes when making the PR.

I just re-ran the calculation and this is what I get

Before:

⛄  2.5.1 🚀  ~/Documents/projects/codetriage (schneems/6.ohhh)
$ bundle exec derailed exec perf:objects | grep Total
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:27: warning: constant ::Fixnum is deprecated
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:91: warning: constant ::Fixnum is deprecated
Total allocated: 760595 bytes (7037 objects)
Total retained:  18789 bytes (166 objects)

After:

⛄  2.5.1 🚀  ~/Documents/projects/codetriage (schneems/6.ohhh)
$ bundle exec derailed exec perf:objects | grep Total
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:27: warning: constant ::Fixnum is deprecated
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:91: warning: constant ::Fixnum is deprecated
Total allocated: 741698 bytes (6646 objects)
Total retained:  18804 bytes (165 objects)
Member

schneems commented Sep 20, 2018

Correct I flipped the bytes when making the PR.

I just re-ran the calculation and this is what I get

Before:

⛄  2.5.1 🚀  ~/Documents/projects/codetriage (schneems/6.ohhh)
$ bundle exec derailed exec perf:objects | grep Total
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:27: warning: constant ::Fixnum is deprecated
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:91: warning: constant ::Fixnum is deprecated
Total allocated: 760595 bytes (7037 objects)
Total retained:  18789 bytes (166 objects)

After:

⛄  2.5.1 🚀  ~/Documents/projects/codetriage (schneems/6.ohhh)
$ bundle exec derailed exec perf:objects | grep Total
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:27: warning: constant ::Fixnum is deprecated
/Users/rschneeman/.gem/ruby/2.5.1/gems/will_paginate-3.1.0/lib/will_paginate/view_helpers/link_renderer.rb:91: warning: constant ::Fixnum is deprecated
Total allocated: 741698 bytes (6646 objects)
Total retained:  18804 bytes (165 objects)
@tomca32

This comment has been minimized.

Show comment
Hide comment
@tomca32

tomca32 Sep 20, 2018

👍 Thanks for taking the time to explain.

tomca32 commented Sep 20, 2018

👍 Thanks for taking the time to explain.

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