Fixing JSF state saving: Save vs. Restore

(A bit of esoterica, but probably of interest here to those deeply focused on JSF performance...)

An update: I got a chance to take some timings. As expected, saving state is now much faster: 85-90% faster, roughly equivalent to the improvements in the size of the saved state. But I was very surprised to discover that restoring the view isn't any faster, perhaps even marginally slower - until I realized that was the only possible result.

Restore View has to create a full tree, starting from zero. What could possibly be faster than creating that tree from an object tree that specifies every attribute that needs to be set, every class name that needs to be instantiated? Put another way, the old restoreVIew() approach, for all of its memory inefficiencies, is essentially an equivalent workload to building the tree in the first place, and might be even faster. This new approach starts with the overhead of building the tree from scratch, plus the overhead of setting some additional state. (That additional overhead is fairly negligible, but the point remains: fixing JSF state saving doesn't make Restore View fast.)

A slight clarification, BTW: I'm not using client-side state saving a la the RI or MyFaces, which serializes the entire tree to the client. Instead, we use ADF Faces's tokenized client-side state saving - run saveSerializedView, but then stash the result on the session, and only send a token to the client. If we were using fully serialized trees, then you would get a performance boost even in Restore View, because you'd only have to unserialize a small block, instead of the whole thing.

So, does that mean that restoreView() is necessarily slow? Well, no. There are approaches to optimizing restoreView(). The most direct is optimizing building the component tree - which will help both with initial component tree creation and with restoreView(). How to do that in another post. (Hint: FacesBean and Facelets are a huge help here, too!)