I haven't broken down the performance/memory aspect out from overall
benchmarks. I know that for size of the serialized, Base64'd, gzip'd
content, there's relatively little difference - the Facesbean approach
is maybe 10% better - especially because the arrays full of nulls end
up getting gzip'd down pretty well. It'd be interesting to see how
the CPU and memory requirements differ in the two strategies
The big wins are first, code complexity (only minimal overrides of
saveState()), and second and more importantly, a central location for
adding optimizations, like I talk about in the second blog entry. You
*could* implement delta support without a central state object, but
yeesh, what a nightmare!
There's also some significant benefits in this architecture in terms
of rendering performance; we can retrieve a property far faster than
getAttributes().get("attrname"), which rapidly becomes one of the
major bottlenecks in rendering performance.
-- Adam
On 3/2/06, Werner Punz <[EMAIL PROTECTED]> wrote:
> Adam I really love the idea of having a central state saving request
> singleton.
>
> Any numbers on how much performance and ram improvement you get with
> this method compared to the classical we do a simplified serialisation
> per component approach myfaces (and probably the ri as well) use.
>
>
>
>
> Adam Winer schrieb:
> > I've written a couple blog entries on this:
> >
> > http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html
> >
> > ... and this morning's:
> >
> > http://sfjsf.blogspot.com/2006/03/how-were-going-to-fix-jsf-state-saving.html
> >
> > Cheers,
> > Adam
> >
>
>
