Why is internal view state size counted against the developer?

Question

Why is "internal view state" counted against the developer?

If I have 4k worth of data in the page view state but the VF page structure uses a myriad of nested <apex: tags, such as <apex:repeat /> over map collections of this data in the controller and <apex:outputLabel /> and <apex:inputText /> for data capture and the VF page renderer generates 132k worth of 'internal view state' why is that a problem which is enforced by a limiter?

1. Why isn't the 135k view state limit measured against user data, which the developer truly has control over? Maybe a 15k user data limit would be more flexible to the developer regardless of the internal view state size.
2. Is there a black-box setting to allow a page to use more than 135k?
3. Is there a future config option in the works to allow the developer to specify the limit they would expect to not exceed?

Answer 1

1. The total view state size affects performance; the limit of 135k was chosen as a point where performance is still manageable. While developers have only limited control over the view state size, a large internal state size indicates that the page needs to be optimized by the developer. The view state is sent with every request (except in the new pilot, where the state is stored server side), but more importantly, it has to spend time serializing and deserializing, which is further complicated by the fact that view state is also encrypted.

2. As far as I'm aware, there's no such feature currently in place. Again, the platform limit is in place to manage performance, not to penalize the developer directly. Once you start creeping past 135kb of state, the system starts to act very sluggishly, even if there are no complex queries involved. It's possible that this may change in the future, but for now, the best choice a developer has is to avoid expensive components as much as possible, and repeat, datatable, and pageblocktable is currently the worst offenders (even more so when using maps and lookups nested inside these structures).

3. There's no idea specifically for an arbitrary state size increase per developer, which would let them fine tune performance versus functionality, but the there are some ideas on the IdeaExchange about increasing the limit in general (such as to 256k).

That aside, there are things that you can do to minimize view state:

• Use wrapper classes instead of maps. They are cheaper and hold up well in terms of scaling. You can even use custom getters and setters to internally map wrapper items to a map-- maps are far more efficient in Apex Code.

• Use Apex Code to formulate expressions whenever possible. {!OR(flag1, flag2, flag3)} is not as efficient as {!flags1_2_3}, where the value is computed in the controller.

• Avoid repeating tags when possible, especially nested repeating tags. As previously stated, repeating structures are the worst offenders, because each element has to be encoded inside the repeat. This practically limits developers to just a couple hundred iterations per request.

• Avoid non-transient data. You can often get away with a far smaller view state if you discard information that can be recalculated or reconstructed each page iteration. For example, it's often not necessary to store the results of a query in memory directly-- just the ID values that the query produced. It's fast to query by ID values, because the system is designed to do this.

• Use remoting whenever possible. The new remoting mechanism lets you render the data client-side, and you can store it all outside the view state. Client-side is the new mantra, and while it has some challenges (such as having a consistent way to use multi-currency formatting), it certainly avoids much of the view state problem.

• Don't go for "pixel perfect." This was actually in a guide I was reading written by someone at salesforce.com. It's okay to not be "perfectly aligned", if that means you can save view state size/performance. For example, use <a href instead of <apex:outputLink when practical, and use {!Object__c.Field__c} instead of <apex:outputText value= whenever possible. It's even possible to calculate the visibility or editability of fields in Apex Code, and dynamically render those elements to reduce view state size.