[seam-dev] Seam Startup Performance

Pete Muir pmuir at redhat.com
Sun Jul 10 13:46:14 EDT 2011


I think there are significant improvements to be made in Weld as well to improve startup time if we follow through with the redesign of the architecture to only build needed meta-data - the majority of startup time is spent building metadata for classes that probably don't need it. Hopefully we will get some more staffing on Weld soon to see these changes happen :-)

I don't think there is any reason to not have portable extension notifications to be fired concurrently, though like you say this will trip up a lot of existing extensions.

On 9 Jul 2011, at 02:33, Stuart Douglas wrote:

> There is some multi threaded stuff that can be done, and I am hoping to do it for AS 7.1.
> 
> We could also optionally have a setting that allows portable extension notifications to be fired asynchronously, although you would need to make sure that all PE's in your add were thread safe. This would provide a massive boost to startup time.
> 
> Stuart 
> 
> 
> 
> On 09/07/2011, at 10:39 AM, Jason Porter wrote:
> 
>> I've wondered about the start time of Seam 3 apps. Seems like it takes a while. 
>> 
>> Lincoln: you on 1.1.1.Final now?
>> 
>> I've also wondered if event notification could be done or is done in a multi threaded way. We start getting a lot of those first life cycle calls going to many archives and it probably starts taking a bunch of time. 
>> 
>> Sent from my iPhone
>> 
>> On Jul 8, 2011, at 18:25, "Lincoln Baxter, III" <lincolnbaxter at gmail.com> wrote:
>> 
>>> God, doing that in Forge would be a nightmare. Too many classes, too many beans. I just need weld to start up faster!
>>> 
>>> On Fri, Jul 8, 2011 at 7:45 PM, Dan Allen <dan.j.allen at gmail.com> wrote:! 
>>> 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 Allen
>>> Principal 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
>>> 
>>> 
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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




More information about the seam-dev mailing list