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

perf: precompute DEFAULT_TARGET_WIDTHS to avoid repeating the work in client.path(..) #105

Merged

Conversation

stevehodgkiss
Copy link
Contributor

Description

Path.new / client.path(..) re-computes the same default target
widths on each call. It can be computed once on boot rather than with
each client.path call. The @default_target_width might not actually
be used if srcsets aren't being generated and widths isn't specified,
so it doesn't make sense to perform this work in the initializer.

Before:

❯ be ruby script/bench_path.rb
Warming up --------------------------------------
Imgix::Path#initialize
                        19.625k i/100ms
Calculating -------------------------------------
Imgix::Path#initialize
                        195.167k (± 0.7%) i/s -    981.250k in   5.027994s

After:

❯ be ruby script/bench_path.rb
Warming up --------------------------------------
Imgix::Path#initialize
                       107.620k i/100ms
Calculating -------------------------------------
Imgix::Path#initialize
                          1.067M (± 0.9%) i/s -      5.381M in   5.045179s

`Path.new` or `client.path(..)` re-computes the same default target
widths on each call. It can be computed once on boot rather than with
each `client.path` call. The `@default_target_width` might not actually
be used if srcsets aren't being generated and `widths` isn't specified,
so it doesn't make sense to perform this work in the initializer.

Before:

```
❯ be ruby script/bench_path.rb
Warming up --------------------------------------
Imgix::Path#initialize
                        19.625k i/100ms
Calculating -------------------------------------
Imgix::Path#initialize
                        195.167k (± 0.7%) i/s -    981.250k in   5.027994s
```

After:

```
❯ be ruby script/bench_path.rb
Warming up --------------------------------------
Imgix::Path#initialize
                       107.620k i/100ms
Calculating -------------------------------------
Imgix::Path#initialize
                          1.067M (± 0.9%) i/s -      5.381M in   5.045179s
```
@stevehodgkiss stevehodgkiss requested a review from a team as a code owner March 31, 2021 16:49
@commit-lint
Copy link

commit-lint bot commented Mar 31, 2021

Performance Improvements

  • precompute DEFAULT_TARGET_WIDTHS to avoid repeating on Path.new (5a3fedc)

Contributors

stevehodgkiss

Commit-Lint commands

You can trigger Commit-Lint actions by commenting on this PR:

  • @Commit-Lint merge patch will merge dependabot PR on "patch" versions (X.X.Y - Y change)
  • @Commit-Lint merge minor will merge dependabot PR on "minor" versions (X.Y.Y - Y change)
  • @Commit-Lint merge major will merge dependabot PR on "major" versions (Y.Y.Y - Y change)
  • @Commit-Lint merge disable will desactivate merge dependabot PR
  • @Commit-Lint review will approve dependabot PR
  • @Commit-Lint stop review will stop approve dependabot PR

Copy link
Contributor

@ericdeansanchez ericdeansanchez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also omit the call to TARGET_WIDTHS.call altogether if we generate and assign the DEFAULT_TARGET_WIDTHS once (i.e. just an array of 31 values [100, ..., 8192]). The only issue with this is remembering to update this array (maybe the min/max/tolerance defaults change). To solve for that, we could test that the DEFAULT_TARGET_WIDTHS = [...] array is the same as calling TARGET_WIDTHS.call(DEFAULT_WIDTH_TOLERANCE, MIN_WIDTH, MAX_WIDTH). Just my 2¢

Otherwise this lgtm 👍

Copy link
Contributor

@sherwinski sherwinski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this @stevehodgkiss! Definitely a marked improvement 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants