Change example in "Copying data is not always bad" section of Performance Tips #45865
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The previous example shows only a minor speedup for copying, and further, I could not reproduce that speedup at all when copying the example into a 1.7 or a 1.9 REPL. I couldn't find any example where copying the data sped up operation unless it was accessed repeatedly. Consequently, I changed the example to one with repeated access, and changed the prose to reflect the significance of repeated access. This makes sense to me because it seems difficult to recoup the cost of irregular access during a copy by avoiding a single irregular access during operation.
Repeated multiplication is silly because it makes more sense to raise A to a power first, so I added a ReLU activation function and made the example into a full neural network. It's the simplest sensible example I could come up with.