Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm having performance issues on a Rails 3.1.0 application, now I've done dome changes on my queries with AR and so but views still takes too many time to render, I've divided the views, loops and so, on many partials that are rendered dynamically inside views and inside other partials.

So it's a bad practice to have a large number of partials?

Should I reduce the number of partials to improve the views rendering time?

Thanks

share|improve this question

3 Answers 3

up vote 5 down vote accepted

I know about no significant rendering performance difference between many partials and one single view when you render the same content.

Obviously, if you render only some partials in some cases and others in other cases, such effectively reducing the rendering volume of a specific view, than you may gain some speed.

On the other hand, I always considered partials abstractizations which should be used at least from 2 different places to justify their existence. The other reason to use partials is when you want to render the same view but load different partials based on some business logic you have.

UPDATE:

I can't offer a measurement or some concrete numbers about the rendering speed. If you use a partial in a view, to render it you call the render method, so there is a second method call. This, as I said in my answer, is almost nothing but may help speed up things a very little.

However I never heard of a project fixing its performance problem by removing partials. Partials are a good way to offer a reuse mechanism to views and from the programmers view they should be used for that scope. They should be abstractizations for common concepts in views.

I worked on a project where partials were excessively used. Not Rails, but same MVC principles. Using little partials for everything you can imagine makes them hard to find when you start to have dozens of them. Where would you look for an input to be modified? In the view? In a partial? In which partial, there are 4 partials for this view? ...

After some hard refactorings, with each update of a view, we removed the unnecessary partials. They did not disappeared completely, but what remained are abstractizations which are well defined for the project. They represent well understood elements (like a tree for some kind of objects, or a specific list type) which repeat in a form or other on several views. I know if I see a tree that there is a partial for that. I know when I see certain type of list that there is a partial for that. I don't have hunt them down.

Code readability is the most important thing one can do for a software code base.

share|improve this answer
    
So basically, if i don't really need a partial, if that code will not be reused by other controller o reloaded dynamically i should't use partials? and this would improve the views rendering time? –  Mr_Nizzle Jul 20 '12 at 14:52
    
@Mr_Nizzle: I updated my answer to cover the problems rose by your comment. I hope this expended explanation is more understandable ... I just realized that my second paragraph in the answer can be misunderstood. –  Patkos Csaba Jul 20 '12 at 20:41
    
Thanks man Code readability, that's what's all about. –  Mr_Nizzle Jul 20 '12 at 20:49

I disagree with both answers. I have copied and pasted the code from a partial into the position that it is present in the parent view partial and with 500 iterations, this takes a huge 600ms off the time take to render the view. <%= render xyz %> is in my opinion very broken.

Example, total time to render view:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

Edited

I ended up unDRYing all _partials within the _model partial and got it down to ~2000ms, at which point I tried moving the _model partial into the index however this did NOT have any affect on rendering times so I guess it's with calls to nested render that does it.

share|improve this answer
    
Interesting finding on nested partial. Did you mean unDRYing one partial reduced 600ms, and unDRYing all partials reduced 3800ms? Could you release the demo app for that? –  lulalala Jun 19 '13 at 9:32
    
@lulalala yes exactly, and sorry I can't as it was for my work and I've now moved it off Rails to Django so not even in touch with that code anymore. Looking at Wyatt Barnett has answered, I'm also now not sure if actually under the hood the partials were doing inefficient DB accesses which my unDRYed code was somehow avoiding. –  AJP Jun 19 '13 at 10:38
    
I've found the same thing. Taking code out of partials and unDRYing up the view gave me ~450ms performance increase as well. –  bcackerman Mar 12 at 3:01

Not a rails guy, but Partial Views are likely not the problem per se. Rather, it sounds like you are doing a bit of SELECT N+1. Look at things from the DB server's perspective to make sure you aren't beating it to a pulp.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.