Hacker News new | past | comments | ask | show | jobs | submit login

Views are definitely one of the places that can get slow. Each partial is an IO read and they happen sequentially. Looping and rendering a partial is a common mistake that kills performance.



> Each partial is an IO read

No it's not. Once a partial has been compiled into bytecode, Rails doesn't reach to disk anymore, it's all in memory.


This article says otherwise:

https://scoutapm.com/blog/performance-impact-of-using-ruby-o...

Maybe it has changed but either way they still can be a bottle neck


Yeah, that article is incorrect about the IO part, unless somehow they've been testing in development or something like that.

It's however correct that partial rendering is quite more costly than it should, I explain why elsewhere in this thread.


That gives me a 500 error.

At any rate, I think many rails developers should refresh their knowledge of rails caching: https://guides.rubyonrails.org/caching_with_rails.html.

For example using the data from the db (model instance) as cache key is quite effective solution for being able to deliver most view/fragments from cache.

The downside is that some care must be taken with keys, which parts are cached (eg: logged in pages).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: