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" <[email protected]> >> 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 <[email protected]> wrote:! >>> On Fri, Jul 8, 2011 at 19:27, Stuart Douglas <[email protected]> >>> 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 >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >>> >>> >>> >>> -- >>> Lincoln Baxter, III >>> http://ocpsoft.com >>> http://scrumshark.com >>> "Keep it Simple" >>> _______________________________________________ >>> seam-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/seam-dev >> _______________________________________________ >> seam-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > seam-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
