[seam-dev] Seam Startup Performance

[Mark Struberg]

Btw, a small side note on the 'manual' way you took in some Extensions:

I now had to look at Seams persistence module because we got an OWB bug reported in conjunction with seam-persistence and I like to state that it is really hard to track down the producer for the EntityManager, etc because Seam does _not_ use CDI mechanics but instead provide all this stuff guice-like via AnnotatedTypeBuilder in an Extension.
This is almost impossible to debug and to track down!
Especially since this effectively disables all IDE tools for CDI.

LieGrue,
strub

--- On Sun, 7/10/11, Mark Struberg <struberg at yahoo.de> wrote:

> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [seam-dev] Seam Startup Performance
> To: "IIILincoln Baxter" <lincolnbaxter at gmail.com>
> Cc: "Seam Dev List" <seam-dev at lists.jboss.org>
> Date: Sunday, July 10, 2011, 11:31 AM
> Of course, we'd first need to do a
> performance evaluation to see if it would help a lot.
> 
> In OpenWebBeans we did it 'half way' now. Whenever we
> detect that a class doesn't have any Scope annotation
> (directly or indirectly via an @Stereotype), nor any @Inject
> or @Produces inside, we only initialize the bean meta info
> as an empty shale. And if it gets injected into another bean
> later, we just initialize this bean lazily. 
> 
> Of course, this trick didn't help that much with scanning
> performance (maybe ~15%), but it greatly reduced the memory
> footprint.
> 
> Btw, we really should spec the exclude paths in beans.xml.
> I now found the regarding issue already filed in 
> https://issues.jboss.org/browse/CDI-87
> I added a proper description, but Pete, could you please
> edit the title and give it a more meaningful text? :)
> 
> LieGrue,
> strub 
> 
> 
> --- On Sat, 7/9/11, Lincoln Baxter, III <lincolnbaxter at gmail.com>
> wrote:
> 
> From: Lincoln Baxter, III <lincolnbaxter at gmail.com>
> Subject: Re: [seam-dev] Seam Startup Performance
> To: "Mark Struberg" <struberg at yahoo.de>
> Cc: "Stuart Douglas" <stuart.w.douglas at gmail.com>,
> "Dan Allen" <dan.j.allen at gmail.com>,
> "Seam Dev List" <seam-dev at lists.jboss.org>
> Date: Saturday, July 9, 2011, 11:00 PM
> 
> At this point, I think that may actually be a good option.
> I can't get forge to start up in under 8 seconds anymore.
> I'm all for doing this I suppose, though it will be a bit of
> a departure from the current functionality. I like the
> auto-pickup, but this performance is pretty attrocious :(
> 
> 
> On Sat, Jul 9, 2011 at 8:40 AM, Mark Struberg <struberg at yahoo.de>
> wrote:
> 
> Folks, what if we step back and fix the CORE of this
> disaster?
> 
> 
> 
> Lets not pickup non CDI scope annotated beans as @Dependent
> automatically anymore!
> 
> 
> 
> We could automatically enable this feature if we detect a
> version="1.1" in beans.xml. This way we can keep backward
> compatibility
> 
> 
> 
> LieGrue,
> 
> strub
> 
> 
> 
> --- On Fri, 7/8/11, Dan Allen <dan.j.allen at gmail.com>
> wrote:
> 
> 
> 
> From: Dan Allen <dan.j.allen at gmail.com>
> 
> Subject: Re: [seam-dev] Seam Startup Performance
> 
> To: "Stuart Douglas" <stuart.w.douglas at gmail.com>
> 
> Cc: "Seam Dev List" <seam-dev at lists.jboss.org>
> 
> Date: Friday, July 8, 2011, 11:45 PM
> 
> 
> 
> On Fri, Jul 8, 2011 at 19:27, Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
> 
> 
> 
> 
> 
> Hi Guys,
> 
> 
> 
> 
> 
> 
> 
> I was just looking at the startup performance of the Seam 3
> booking example on AS7, and I noticed that because the Seam
> 2 archives that it deploys are bean archives, it actually
> wastes quite a lot of time on startup registering Seam 3
> classes as CDI beans that are never used.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> It occurred to me that we can get around this by using a
> beans.xml that includes welds <scan> extension in
> beans.xml to prevent uneeded beans being registered we could
> significantly improve the performance and memory usage of
> Seam 3 apps.
> 
> 
> 
> 
> 
> 
> 
> 
> Now that the ridiculous visibility and extensions in
> non-bean archive problems are resolved, I'm in favor of
> switching back to registering beans manually rather than
> using beans.xml. That seems like a performance enhancement
> that's portable, so that we don't suck if Weld isn't the
> provider.
> 
> 
> 
> 
> 
> 
> But I agree we should do one of the two options. We'll be
> moving tests around in Seam to align the setup, so it seems
> like a good time to run tests with the updated bean
> registration strategy.
> 
> 
> 
> 
> 
> -Dan
> 
> --
> 
> Dan AllenPrincipal Software Engineer, Red Hat | Author of
> Seam in Action
> 
> Registered Linux User #231597
> 
> 
> 
> http://www.google.com/profiles/dan.j.allen#about
> 
> 
> 
> 
> 
> http://mojavelinux.com
> 
> http://mojavelinux.com/seaminaction
> 
> 
> 
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> 
> 
> _______________________________________________
> 
> seam-dev mailing list
> 
> seam-dev at lists.jboss.org
> 
> https://lists.jboss.org/mailman/listinfo/seam-dev
> 
> 
> 
> 
> 
> _______________________________________________
> 
> seam-dev mailing list
> 
> seam-dev at lists.jboss.org
> 
> https://lists.jboss.org/mailman/listinfo/seam-dev
> 
> 
> 
> 
> -- 
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
> 
> 
> 
> 
> 
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>