memory use for one, but the real issue is replication bandwidth in a cluster
and serialization overhead. it's still really expensive and slow to
serialize stuff.
we need our components to be super lightweight. if we "fix" this by using
LinkedList, yeah, it will be a bit simpler, but we'll introduce overhead to
wicket that will cause users to complain about session size eventually
and we'll
wind up tuning this exact spot of code which i identified in size
profiling 9 months
ago using this exact method. that's my belief. same goes for the other
things
that are size-tuned in wicket.
1. Component flags are bits
2. Container maps are optimized to use super-space efficient map
implementations for containers with few components (this makes a HUGE
space difference in profiling)
3. Validators are chained manually
i really don't think there are any other cases where we've tuned things
like this.
these are the three places that showed up in profiling as significant
and they've
each been dealt with... although it might be time to re-run the
size-profiling again...
it's surprising what creeps in when people aren't thinking about the
real cost of
wicket components in terms of space.
jon
Phil Kulak wrote:
Why do you think that using a LinkedList would add more data to the
session? I mean, what would be so bad about this?
On 8/11/05, Jonathan Locke <[EMAIL PROTECTED]> wrote:
the order is also not guaranteed. and the non-existent ordering
contract is with add()
not validator list. that's implementation that should not be exposed.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
