It depends on the state saving mode you are using. If you are using client side state saving, the information related to the view is stored into javax.faces.ViewState hidden field parameter. When the server receives the request, it creates the view from the state, process it and write the field in the response. If you are using server side state saving, the state is stored into session, so in some cases the old state is there, but there is an algorithm that discard the old views from the session.
With JSF 2.0 Partial State Saving (PSS) the view is derived from two things: the initial state and the delta state. The initial state is derived from building the view again using facelets algoritm. So what's stored as view state is just an small fraction of the overall state. The trick is very effective indeed, so after that improvement people doesn't need to care about state size anymore with JSF. That has resulted in a very good performance compared with stateless frameworks. See Understanding JSF Performance part 3 on JSFCentral
In Apache MyFaces 2.2 there is a view pool algorithm. The idea is take advantage of the state saving algorithm and use it to reuse views already built. It can give you a boost in performance of about 8-10%, but third party libraries needs to be compatible with this approach. See How to configure View Pool in Apache MyFaces. This was thought as a solution to get the "ultimate performance", but most of the time you'll do it fine using without it.
Facelets algorithm with PSS enabled is called in two points: when the view is build or restored and before render response phase to refresh the components like c:if and so on.