On 9/8/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: > Hi Eelco, > > Thanks for the thorough response (as usual). We're almost done > converting from Tap 4 to Wicket 1.2 and we'll look into migrating to > 1.3 pretty soon. I was planning on reverting to the HttpSessionStore > immediately because I assumed the new disk-based store(s) traded > performance for memory efficiency (and we have the luxury of not > really caring about RAM usage due to a limited number of users in a > LAN-only environment). > > An old benchmark that Jonathan posted (http://www.jroller.com/ > JonathanLocke/entry/how_fast_is_wicket) suggested the > HttpSessionStore was noticeably faster, but I know there have been a > lot of performance improvements since then. > > I've been pretty cynical about the whole idea of a disk-based store, > actually. It always seemed like "jumping a fence" into a servlet > container/app server's area of responsibility (had a slightly nasty > argument with Johan about that). While it always sounded like a cool > and very powerful/useful *option* to build into the framework, I > never thought it would be a clear winner over HttpSessionStore. My > main fear was that it would lead to a kind of split between some > people using one store and some the other, and that it might cascade > further into the framework (e.g. design x is a better fit with SLCSS > but design y is better for HttpSessionStore) ultimately becoming a > big drag for you guys. > > So that's a long way of saying: damn, I'm impressed. Not only is > 1-2ms negligible, it sounds like the SLCSS is a conceptually simpler > approach. Oh, and sorry to Johan for being a skeptic. ;)
I owe him an apology too in that sense, as I was one of the people most opposed to it initially. That turned out to be a premature optimization related fear I had. Also thanks to Matej who recently added a very, very optimized page store variant, *and* contributed an efficient page store that can be used in a cluster. And thanks for both of them for doing some pretty smart optimizations on serialization of pages (which I completely missed at first). Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
