-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
What is the expected slowdown of using SimpleForm? #1227
Comments
Hey @maxwell. According to the profiler SimpleForm spends a lot of time for trying to translate hints and placeholders for inputs. I tried to disable them with |
Same issue here. Forms with 2-3 inputs take up to 400-500ms to render. |
Right. The issue is that, as we add more fallbacks, I18n is just going to be come slower and slower. That's why we had discussions in the past to make this stuff opt-in or reduce the amount of fallbacks. |
Yeah, we have to make them opt-in |
oh man, just was looking into this because I have a form with over 30 fields and it takes like 20 seconds just to render it. Hoping a fix comes soon :/ |
Something is definitely fishy though. Even If it takes about 100ms per field, there is something drastically wrong with I18n. Are you using the default storage or some special backend? Is it reproducible in new applications? We should also remove the amount of fallbacks in our inputs. |
Can you guys tell me which I18n version you're using? Maybe there's something going on there that we didn't catch. |
We have 3 levels deep nested attributes, so this recursion https://github.com/rails/rails/blob/4-1-stable/actionview/lib/action_view/helpers/translation_helper.rb#L37 is called 45 times x ~2.5ms per input. |
Interesting @varyform, thanks for the pointer. I think we can definitely speed that up to start with. |
@carlosantoniodasilva forgot to mention important thing: the problem exists in development mode only |
Hm, so your case might be related to reloading then. How many different locales do you have? (You can check that in the console with |
Just one locale in my app, with very few translations. It's basically a brand new app started last week. |
I have the same issue with a fresh Rails 4.2.1 app (i18n (0.7.0)): Adding Limiting locales to only default :en didn't seem to help. |
Same here with Rails 4.2.1 app (i18n (0.7.0)) and Ruby 2.2.2 In production or development
My locale file: pt-BR:
activerecord:
models:
contract/contract : "Contrato"
attributes:
contract/contract:
representative_id : "Representante"
telemarketing_id : "Telemarketing"
number : "Numero"
client_company_id : "Empresa desse contrato"
signature_date : "Data de assinatura"
observation : "Observação"
items : "Itens do contrato"
price : "Valor contrato"
parcels_number : "Parcelas"
first_parcel_date : "Primeiro vencimento"
total_payments_price : ""
one_contract_payment : "" Definitely is a problem with I18n https://github.com/plataformatec/simple_form/blob/master/lib/simple_form/inputs/base.rb#L172 I remove some lines inside this functions and disable translate_from_namespace from placeholders def translate_from_namespace(namespace, default = '')
model_names = lookup_model_names.dup
lookups = []
lookups << :"#{model_names.join(".")}.#{reflection_or_attribute_name}"
lookups << default
t(lookups.shift, scope: :"#{i18n_scope}.#{namespace}", default: lookups).presence
end After that
I love SimpleForm, I'm sure you will find a good solution. |
In my case form is rendered for like 10-20 seconds in development, in production the time is ok. Profiler points to i18n also |
I sped up the rendering of my form almost 3 times by adding these defaults:
What happened that this is suddenly so slow? A change in rails 4.2.1? The form rendered much faster before. |
See heartcombo/simple_form#1227 for some more details. Also added slim and started translating some templates.
I finally got around to profiling my app after thinking Rails 4.2 was the culprit of my horrendously slow form load times, but finally narrowed it down to simple form. If I use simple_form < 3.1 then my issues go away, but using 3.1, the translation issue slows everything to a crawl. diegorv's solution works for me for now though. |
SimpleForm looks up for translation in a huge amount of places which slows it down when you use nested forms. See issue: heartcombo#1227 Removed the nested lookups code (including the while-loop) completely as suggested by @diegorv.
Same problem here - rendering ~20 forms with ~8 form fields each leaves me at 10 seconds + rendering time (in development mode) , setting the defaults: |
Thanks for all the info so far folks. On another thread, people were reporting that removing "web-console" was removing the slow down. Can you please verify you achieve good performance by temporarily removing it? @diegorv can you please send a PR with your changes? You don't need to make the tests pass, I would just like a diff of the changes you have done to help debug this further. Thanks everyone! |
FWIW, my project does not use web-console. |
@josevalim We were able to realize a significant speedup in production by removing the placeholder and hint options from the wrapper config initializer. We don't use web-console, binding_of_caller or better errors. |
Thanks @uhlenbrock. Yes, there is something that simple form depends on that became suddenly slower, it may be the I18n plugin or a dependency monkey patching something. I am trying to collect more information before I dive into this. :) |
Yes, I do use that. :). Sorry, should have used my brain. I will disable and get back to you
|
done @josevalim :) |
Removing web-console does improve things somewhat, but it's still not as fast as the recommendation by diegorv (which still allows the web-console gem). The main issue is that a lot of translation lookups are simply failing. I generated a flamegraph around a single input and had approximately almost 20 failed lookups; all those failed lookups add up to A LOT of wasted rendering time with multiple inputs. |
@uhlenbrock Could you please tell if you use |
Okay so for me removing the 'web-console' gem and by extension its dependencies Thanks for the feedback and help! |
@mib32 No, I do not. |
Tossing my experience with the issue to the mix. I'm running Rails 4.2.1 on Ruby 2.1.1 with SimpleForm 3.1.0. I landed on this issue because like some others here, I had a form with 8 inputs that was taking 5 to 6 seconds to render. I placed debug statements to try and figure out what was going on only to have the render times increase up to 9 seconds through my testing. I don't use web-console, but I do use better_errors. Trying the suggestions here and from #1237, I disabled better_errors and byebug and restarted my development server. Lo and behold, my form was rendering in 170ms. Great! But I was suspicious. I reenabled those gems, restarted, and the form was still rendering in 170ms. And the rendering time remained stable through a dozen or so page refreshes. However, when I added I haven't profiled anything, but I'm guessing that calling Additionally, following the suggestion to add For what it's worth, I brought the render times back up to 5 seconds and ran |
@josevalim I will corroborate the conclusions of others on this thread that i18n MissingTranslations is the culprit. I think the Running a reduced version of my view through ruby-prof, the number of calls to
The raises of I think the reason Just to be completely thorough, I wanted to verify that MRI2's stack walk code wasn't somehow causing a huge slowdown (it shouldn't since it's some very straightforward pointer math). To do this, I downloaded Hope this helps! |
Thank you for the overview. Maybe a fix is to just use I18n.translate instead of translate or t in simple form? Do we gain anything by using the latter ones? |
@awong-dev thank you for the detailed wrap-up! I have done two changes to master:
Folks on this thread, can you please try master out? Does it fix the performance issues you have seen so far? |
@josevalim Works for me 👍 |
@josevalim Works for me too! 👍 |
@josevalim Thanks for the fast response! I'm not super familiar with the i18n features in rails, but reading through the docs in http://api.rubyonrails.org/classes/ActionView/Helpers/TranslationHelper.html, I'm wondering if 6ba68fc constitutes an abstraction break. At first glance, ActionView::Helpers::TranslationHelper#translate seems to be inserting an API layer for rails apps to override the translate call without having to do something crazy like monkeypatching I18n itself. I'm not at a computer today so it's hard for me to do much research, but my worry is there still isn't an explanation for why SimpleForms was generating so danged many calls to |
👍 works! |
3.2.0 released with the performance fix. Thanks everyone! |
👍 |
Works nicely for me as well. 👍 |
Upgrades SimpleForm from 3.1.0rc2 to 3.20. A noticeable performance decrease was spotted when rendering views in the app after updating to Rails from 4.2.0 to 4.2.4 - in most cases this was increased running times by 4-5x! It appears as though the issues lie with I18n::MissingTranslation's in SimpleForm - something that has been addressed in a later version of the gem. Please see: heartcombo/simple_form#1227 for more info. Updating SimpleForm required a public `has_attribute?` method to be introduced to all form objects.
I was investigating some slow view rendering in our application.
We had a partial that was rendered many times, which looked like this. I had perhaps stupidly opted out of most Simple Form goodness, but I guess for consistency's sake, thought this would be ok.
Worth noting, this f value is coming from a "simple_fields_for" call.
This partial was getting rendered many times, and looking at my logs, each one was taking > 200 milliseconds! eek!
https://gist.github.com/maxwell/12cd7e949cae4ea60766
Changing this to just be normal Rails helpers radically reduced render time, to about 5 milliseconds per partial, 40x faster!
https://gist.github.com/maxwell/f7b6c1bc6625f6b5c3e7
I realize that it is reasonable to know that there would be some overhead, and perhaps one should not use SimpleForms for simple forms which are rendered many times, but is this the kind of overhead we should expect? Am I doing something incredibly stupid to cause this behavior?
I am currently using simple_form (3.1.0.rc1), and Rails 4.1.10
I love using SimpleForm, thanks so much for all the hard work you guys put into it!
The text was updated successfully, but these errors were encountered: