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.
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.