Speed up nested #simple_fields_for usage by a considerable amount #1810
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Exceptions are slow due to generating backtraces - and then when other debugging gems (such as did_you mean, which are included with Ruby and Rails these days) get involved it resulted in excessive Object allocation.
carlosantoniodasilva
approved these changes
Feb 20, 2023
There was a problem hiding this comment.
I had a recollection of seeing something like this before, and sure enough there was a similar PR a while ago: #1725, I just haven't been able to circle back on that one at the time.
This all sounds like a safe change, and hopefully an improvement to the slowness caused by raising/rescuing exceptions in general. Appreciate it!
carlosantoniodasilva
added a commit
that referenced
this pull request
Feb 20, 2023
carlosantoniodasilva
added a commit
that referenced
this pull request
May 14, 2024
This reverts commit b6ae67d, reversing changes made to 0ef4a58. This caused custom inputs to not load properly on non-eager load environments like dev/test, because those constants may not have been defined yet. The previous code would try to constantize them and force-load the lazily-loaded files/constants, the new code breaks that behavior, so we're reverting. Closes #1824, see for more info.
carlosantoniodasilva
added a commit
that referenced
this pull request
May 14, 2024
This reverts commit b6ae67d, reversing changes made to 0ef4a58. This caused custom inputs to not load properly on non-eager load environments like dev/test, because those constants may not have been defined yet. The previous code would try to constantize them and force-load the lazily-loaded files/constants, the new code breaks that behavior, so we're reverting. Closes #1824, see for more info.
|
I'm reverting this change, as it caused a regression. See #1824 for more info. Happy to review something else that fixes the original problem without the regression, but for now we'll have to live with it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
FormBuilder#find_mappingmethod is relying onObject#const_getraising an exception if the constant doesn't exist, rather than directly checking if it exists withObject#const_defined?.Exceptions are slow due to generating backtraces - and then when other debugging gems (such as did_you mean, which are included with Ruby and Rails these days) get involved it resulted in excessive Object allocation.
Normally the
discovery_cachewould mitigate this, so there wouldn't be many calls to#mapping_override, however when you use#simple_fields_forwith a collection/has_many association the cache is empty for each item in the collection.Before this change this code was taking approximately 2 seconds and 2.9million allocations for 235 records:
After this change it was down to approximately 100ms and 200,000 allocations. (All on my M1 MacBook Air)