i just finished a space optimization experiment in wicketcontainer that
paid off...
before space opt
----> Sizeof(wicket.examples.nested.Home) = 69958
----> Sizeof(wicket.examples.helloworld.HelloWorld) = 6706
----> Sizeof(wicket.examples.navomatic.Page1) = 12722
----> Sizeof(wicket.examples.linkomatic.Home) = 43109
after space opt
----> Sizeof(wicket.examples.nested.Home) = 55231
----> Sizeof(wicket.examples.helloworld.HelloWorld) = 6338
----> Sizeof(wicket.examples.navomatic.Page1) = 12034
----> Sizeof(wicket.examples.linkomatic.Home) = 41649
there is a pretty nice sized different in space consumed by a complex
tree like nested (69958 - 55231 = 14,727 bytes saved)
but even small simple pages save by not instantiating a Map instance...
even hello world shrank 368 bytes!
basically, i wrote code that does the same array optimization we did
with the validators...
it's ugly as hell, but a big improvement in efficiency!
although it's not as important as space savings because of clustering, i
suspect that the efficiency of the code may actually be faster as well
because:
- iteration will likely be faster
- map accesses are less common than iteration because of recursion
- many containers have only one or two children
- most other containers won't have enough kids to make a difference in
search speed
- map required computation of hashcode, alloc and cons of entry objects
and map object
and as a bonus, we now have ordering guaranteed so validations will
happen in the order components are added to a form, for example...
jon
-------------------------------------------------------
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
