I should add that these are just the functional gems for a Rails app. For development and testing, I'll still bring in better_errors, binding_of_caller, factory_bot_rails, rspec_rails, simple_cov and dotenv-rails. These fit my development workflow and makes my life a bit easier as a developer. Other gems which do not require to be in the Gemfile that I still like and use are annotate, brakeman, and bundler-audit.
I've looked into this package. It is really cool and I like that they're bringing self hosted options for performance monitoring. However, this tool is missing some key components to be a viable and recommended solution. It doesn't appear to have any kinds of alert settings or notification integrations which is critical for production applications. Otherwise, you would have to manually check the performance app for the health of your application. I can see this app providing some insights into the health of the application, but lacks a lot of the information that others provide.
```In early benchmarks, we’ve seen performance improvements over the existing rendering pipeline. For a test page with nested renders 10 levels deep, we’re seeing around a 5x increase in speed over partials:
Comparison:
component: 6515.4 i/s
partial: 1251.2 i/s - 5.21x slower
```
It is interesting, they're showing 5x difference in some cases. Perhaps one level deep, the difference would be small, but on 10 levels deep, that's a pretty significant change.
I would assume that it has less to do with erb processing and more to do with the modules that are getting loaded in with a normal partial being rendered. In the last example of the episode, we saw how we could add in other modules for stuff like url helpers. There are likely a lot more helpers being loaded in which would account for the extra time to render the partials.
