We did a similar test, and the result where much the same: one use case, two implementations (jsf/ seam vs wicket). Both apps where running inside JBoss and used the same persistence/ service layer. We only did performance tests (no memory analysis), first wicket was faster by a margin of 7-10, after reconfiguring seam/ jsf it was by a margin of 2-3.
After analyzing the behaviour with JProfiler we found the problem: JBoss EL, the expression language (rather a specific implementation of it) used in JSF pages. Most time was spent in some invokeMethod() code. This is a seam issue: https://jira.jboss.org/jira/browse/JBSEAM-1977 which comes from seam using javassist extensivly. Yes, you can workaround by using some idioms or tricks, but personally I don't like technologies where dealing with core stuff requires workarounds. regards, Martin 2009/1/14 Nino Martinez <[email protected]>: > Wild, I did'nt think there was that much of a difference between wicket and > the seam/jsf stack.. > > Again wicket stands out as the winner :) > > Martijn Dashorst wrote: >> >> Peter Thomas wrote a nice article comparing the performance of >> Seam/JSF and Wicket. >> >> You can vote for the article at dzone: >> http://www.dzone.com/links/seamjsf_vs_wicket_performance_comparison.html >> >> Or read the article directly: >> >> http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performance-comparison/ >> >> Many thanks go to Peter for writing this article. >> >> Martijn >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
