We may be able to publish this at some point.
On 29 Jan 2010, at 20:47, Arbi Sookazian wrote:
I would be interested in seeing performance monitoring results for a
load test of the Seam 2.x booking app vs. Seam 3 booking app. Using MySQL db or similar,
not HSQLDB.
Is Seam 3 in a usable state currently? AFAIK it's pre-alpha or alpha so is there any
timeline for a M1 or beta, etc.?
On Fri, Jan 29, 2010 at 11:46 AM, Pete Muir <pmuir(a)redhat.com> wrote:
Well, it largely depends on the problem set you are addressing. This kind of concurrency
is clearly useful on multi-core systems if you are addressing a problem set which which
needs to extensively apply functions to ordered lists (aka sorting).
Seam 3 won't have a huge need to work with such things.
Weld performs all dependency resolution and bean metadata creation at startup, meaning
the runtime overhead of a resolution is O(1) - a hash table lookup. Current measurements
show Weld's metadata startup time to be negliable compared the time taken to read
class definitions - if you can show me otherwise, please send me instructions to reproduce
in a profiler.
Likewise, if you can show me hotspots at runtime, please send instructions to reproduce.
On 29 Jan 2010, at 19:35, Arbi Sookazian wrote:
> Thx for the response Pete. I'm trying to gauge how helpful or critical it will
be to do parallel/concurrent programming via the ParellelArray class
(
http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/extra166y/ParallelA...) like
in TNeward's example for Seam 3 apps or using a JVM language like Scala. And I'm
talking in a Seam 3 context only.
>
> In terms of identifying performance bottlenecks in Seam 2.x apps, it seems much of
it has to do with the JSF lifecycle and Seam interceptors and dynamic injection (injection
occurs on all @In annotated properties in a class whenever a public business interface
method is invoked - and this will most likely change in Seam 3 due to the once only
injection strategy in CDI - inject only upon instantiation of the managed bean).
>
> Would the fork/join frmwk or Scala help at all in terms of performance optimization
or should we be worried more about the db tier which is typically the least scalable of an
n-tier web system? Or other obvious things like 2nd level cache implementation or
avoiding/dealing with n+1 selects problems...
>
> On Fri, Jan 29, 2010 at 11:20 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> We plan to support Java 5 and above for the foreseeable future. So yes, Seam 3 will
be run on Java 7 (as Java SE has backwards binary compatibility) but won't take
advantage of new features in Java 7.
>
> On 29 Jan 2010, at 18:50, Arbi Sookazian wrote:
>
> > Hi all,
> >
> > I just read this interesting article on fork/join frmwk by Ted Neward:
http://www.devx.com/SpecialReports/Article/40982
> >
> > I'm wondering if there are any plans to use or recommend Seam 3 developers
to use the fork/join frmwk in Seam 3 if Seam 3 will run on JDK 7. I'm guessing the
final release dates for OpenJDK and Seam 3 may possibly be around the same time (some time
after June this year?)
> >
> > Will Seam 3 be compatible with Java 7?
> >
> > thx.
> > _______________________________________________
> > seam-dev mailing list
> > seam-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/seam-dev
>
>