You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2011/10/20 22:43:41 UTC
openejb jrat
Hi,
following the start up time of openejb i wondered where we were loosing time
exactly (even if scanning seems to be a good candidate),
to have results just extract the zip, run start.sh (or something similar,
there is only one line in the script ;)) and when the window is opened open
the file openejb.jrat). Then go to hierarchy tab and you'll...that 60% of
the startup time is due to scanning.
here are the info: http://people.apache.org/~rmannibucau/jrat.output.zip
- Romain
Re: openejb jrat
Posted by Romain Manni-Bucau <rm...@gmail.com>.
PS: i excluded the jaxb stuff for technical reason so the missing
information is in the unmarshalling which should be time consuming too
- Romain
2011/10/20 Romain Manni-Bucau <rm...@gmail.com>
> Hi,
>
> following the start up time of openejb i wondered where we were loosing
> time exactly (even if scanning seems to be a good candidate),
>
> to have results just extract the zip, run start.sh (or something similar,
> there is only one line in the script ;)) and when the window is opened open
> the file openejb.jrat). Then go to hierarchy tab and you'll...that 60% of
> the startup time is due to scanning.
>
> here are the info: http://people.apache.org/~rmannibucau/jrat.output.zip
>
>
> - Romain
>
Re: openejb jrat
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes, in openejb we set a finder / module but we don't manage what does a lib
when we delegate.
IMHO it means a lib should be able to get already scanned stuff or allow spi
(or equivalent) to do this job.
but globally i think everybody is agree we need to make less useless
scanning
- Romain
2011/10/21 Mark Struberg <st...@yahoo.de>
> xbean-finder provides the basic functionallity for class scanning, but
> currently each EE container part (CDI, JSF, EJB, JPA, Servlet, BVAL) invokes
> the class scanning on it's own. Thus xbean-finder (*) will get invoked n
> times, scanning the classpath n times...
>
>
> the commons-classscaner proposal will use xbean-finder (or better: a
> cleaned up version with removed deprecated code) under the hood.
>
>
> LieGrue,
> strub
>
>
> (*) there is not only xbean-finder. Libs can also just use plain Java
> ClassLoader to scan for annotations. In OpenWebBeans we currently use
> scannotation for it (though thinking about moving to xbean-finder since
> quite a while).
>
>
>
>
> >________________________________
> >From: Romain Manni-Bucau <rm...@gmail.com>
> >To: dev@openejb.apache.org; Mark Struberg <st...@yahoo.de>
> >Sent: Friday, October 21, 2011 10:18 AM
> >Subject: Re: openejb jrat
> >
> >
> >hmm,
> >
> >
> >a common scanner already exists through xbean no?
> >
> >- Romain
> >
> >
> >
> >2011/10/21 Mark Struberg <st...@yahoo.de>
> >
> >you also have to distinguish between:
> >>
> >>
> >>1.) classpath scanning time itself
> >>2.) information extraction from the scanned classes
> >>
> >>As a whole container, we can reduce 1.) because this part could be shared
> between OpenEJB, OpenWebBeans, Tomcat, MyFaces, etc (all libs which do
> classpathscanning on their own currently). A few weeks back I dropped a
> classscanner proposal to the commons list.
> >>
> >>A rudimentarily working example is on my github [1] though there is lots
> of work needed in the filtering part still.
> >>
> >>The fundamental idea is that once the first 'classscan-client' requests a
> scanning result, the 'classscan-server' will load all registerd
> 'classscan-clients' and will ask them what they need to scan for (marker
> files, which annotations, etc). Then it will do all the scan (via davids
> xbean-finder) in 1 go and afterwards the 'classscan-clients' can get the
> result of the scan which they requested. If a 'classcan-client' doesn't need
> the information anymore (all needed info stored into internal data
> structures after the bootup for example), it can unregister() itself so the
> classscan-server can free the memory.
> >>
> >>a.) first benefit is that we only do one physical class scan and bytecode
> parsing -> safes time
> >>b.) most libraries use Class.getAnnotations() Method.getAnnotations(),
> etc which fill up the PermGenSpace heavily (and permanently) because there
> are no methods in the ClassLoader to drop this information later. If we just
> store this info in standard Maps (via xbean-finder), then we can just clear
> the maps and release the memory once it's not needed anymore
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >>[1] https://github.com/struberg/Apache-commons-classscanner
> >>
> >>
> >>
> >>
> >>----- Original Message -----
> >>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>> To: dev@openejb.apache.org
> >>> Cc:
> >>> Sent: Thursday, October 20, 2011 10:43 PM
> >>> Subject: openejb jrat
> >>>
> >>> Hi,
> >>>
> >>> following the start up time of openejb i wondered where we were loosing
> time
> >>> exactly (even if scanning seems to be a good candidate),
> >>>
> >>> to have results just extract the zip, run start.sh (or something
> similar,
> >>> there is only one line in the script ;)) and when the window is opened
> open
> >>> the file openejb.jrat). Then go to hierarchy tab and you'll...that 60%
> of
> >>> the startup time is due to scanning.
> >>>
> >>> here are the info:
> http://people.apache.org/~rmannibucau/jrat.output.zip
> >>>
> >>>
> >>> - Romain
> >>>
> >>
> >
> >
> >
>
Re: openejb jrat
Posted by Mark Struberg <st...@yahoo.de>.
xbean-finder provides the basic functionallity for class scanning, but currently each EE container part (CDI, JSF, EJB, JPA, Servlet, BVAL) invokes the class scanning on it's own. Thus xbean-finder (*) will get invoked n times, scanning the classpath n times...
the commons-classscaner proposal will use xbean-finder (or better: a cleaned up version with removed deprecated code) under the hood.
LieGrue,
strub
(*) there is not only xbean-finder. Libs can also just use plain Java ClassLoader to scan for annotations. In OpenWebBeans we currently use scannotation for it (though thinking about moving to xbean-finder since quite a while).
>________________________________
>From: Romain Manni-Bucau <rm...@gmail.com>
>To: dev@openejb.apache.org; Mark Struberg <st...@yahoo.de>
>Sent: Friday, October 21, 2011 10:18 AM
>Subject: Re: openejb jrat
>
>
>hmm,
>
>
>a common scanner already exists through xbean no?
>
>- Romain
>
>
>
>2011/10/21 Mark Struberg <st...@yahoo.de>
>
>you also have to distinguish between:
>>
>>
>>1.) classpath scanning time itself
>>2.) information extraction from the scanned classes
>>
>>As a whole container, we can reduce 1.) because this part could be shared between OpenEJB, OpenWebBeans, Tomcat, MyFaces, etc (all libs which do classpathscanning on their own currently). A few weeks back I dropped a classscanner proposal to the commons list.
>>
>>A rudimentarily working example is on my github [1] though there is lots of work needed in the filtering part still.
>>
>>The fundamental idea is that once the first 'classscan-client' requests a scanning result, the 'classscan-server' will load all registerd 'classscan-clients' and will ask them what they need to scan for (marker files, which annotations, etc). Then it will do all the scan (via davids xbean-finder) in 1 go and afterwards the 'classscan-clients' can get the result of the scan which they requested. If a 'classcan-client' doesn't need the information anymore (all needed info stored into internal data structures after the bootup for example), it can unregister() itself so the classscan-server can free the memory.
>>
>>a.) first benefit is that we only do one physical class scan and bytecode parsing -> safes time
>>b.) most libraries use Class.getAnnotations() Method.getAnnotations(), etc which fill up the PermGenSpace heavily (and permanently) because there are no methods in the ClassLoader to drop this information later. If we just store this info in standard Maps (via xbean-finder), then we can just clear the maps and release the memory once it's not needed anymore
>>
>>
>>LieGrue,
>>strub
>>
>>[1] https://github.com/struberg/Apache-commons-classscanner
>>
>>
>>
>>
>>----- Original Message -----
>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>> To: dev@openejb.apache.org
>>> Cc:
>>> Sent: Thursday, October 20, 2011 10:43 PM
>>> Subject: openejb jrat
>>>
>>> Hi,
>>>
>>> following the start up time of openejb i wondered where we were loosing time
>>> exactly (even if scanning seems to be a good candidate),
>>>
>>> to have results just extract the zip, run start.sh (or something similar,
>>> there is only one line in the script ;)) and when the window is opened open
>>> the file openejb.jrat). Then go to hierarchy tab and you'll...that 60% of
>>> the startup time is due to scanning.
>>>
>>> here are the info: http://people.apache.org/~rmannibucau/jrat.output.zip
>>>
>>>
>>> - Romain
>>>
>>
>
>
>
Re: openejb jrat
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hmm,
a common scanner already exists through xbean no?
- Romain
2011/10/21 Mark Struberg <st...@yahoo.de>
> you also have to distinguish between:
>
>
> 1.) classpath scanning time itself
> 2.) information extraction from the scanned classes
>
> As a whole container, we can reduce 1.) because this part could be shared
> between OpenEJB, OpenWebBeans, Tomcat, MyFaces, etc (all libs which do
> classpathscanning on their own currently). A few weeks back I dropped a
> classscanner proposal to the commons list.
>
> A rudimentarily working example is on my github [1] though there is lots of
> work needed in the filtering part still.
>
> The fundamental idea is that once the first 'classscan-client' requests a
> scanning result, the 'classscan-server' will load all registerd
> 'classscan-clients' and will ask them what they need to scan for (marker
> files, which annotations, etc). Then it will do all the scan (via davids
> xbean-finder) in 1 go and afterwards the 'classscan-clients' can get the
> result of the scan which they requested. If a 'classcan-client' doesn't need
> the information anymore (all needed info stored into internal data
> structures after the bootup for example), it can unregister() itself so the
> classscan-server can free the memory.
>
> a.) first benefit is that we only do one physical class scan and bytecode
> parsing -> safes time
> b.) most libraries use Class.getAnnotations() Method.getAnnotations(), etc
> which fill up the PermGenSpace heavily (and permanently) because there are
> no methods in the ClassLoader to drop this information later. If we just
> store this info in standard Maps (via xbean-finder), then we can just clear
> the maps and release the memory once it's not needed anymore
>
>
> LieGrue,
> strub
>
> [1] https://github.com/struberg/Apache-commons-classscanner
>
>
>
> ----- Original Message -----
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > To: dev@openejb.apache.org
> > Cc:
> > Sent: Thursday, October 20, 2011 10:43 PM
> > Subject: openejb jrat
> >
> > Hi,
> >
> > following the start up time of openejb i wondered where we were loosing
> time
> > exactly (even if scanning seems to be a good candidate),
> >
> > to have results just extract the zip, run start.sh (or something similar,
> > there is only one line in the script ;)) and when the window is opened
> open
> > the file openejb.jrat). Then go to hierarchy tab and you'll...that 60% of
> > the startup time is due to scanning.
> >
> > here are the info: http://people.apache.org/~rmannibucau/jrat.output.zip
> >
> >
> > - Romain
> >
>
Re: openejb jrat
Posted by Mark Struberg <st...@yahoo.de>.
you also have to distinguish between:
1.) classpath scanning time itself
2.) information extraction from the scanned classes
As a whole container, we can reduce 1.) because this part could be shared between OpenEJB, OpenWebBeans, Tomcat, MyFaces, etc (all libs which do classpathscanning on their own currently). A few weeks back I dropped a classscanner proposal to the commons list.
A rudimentarily working example is on my github [1] though there is lots of work needed in the filtering part still.
The fundamental idea is that once the first 'classscan-client' requests a scanning result, the 'classscan-server' will load all registerd 'classscan-clients' and will ask them what they need to scan for (marker files, which annotations, etc). Then it will do all the scan (via davids xbean-finder) in 1 go and afterwards the 'classscan-clients' can get the result of the scan which they requested. If a 'classcan-client' doesn't need the information anymore (all needed info stored into internal data structures after the bootup for example), it can unregister() itself so the classscan-server can free the memory.
a.) first benefit is that we only do one physical class scan and bytecode parsing -> safes time
b.) most libraries use Class.getAnnotations() Method.getAnnotations(), etc which fill up the PermGenSpace heavily (and permanently) because there are no methods in the ClassLoader to drop this information later. If we just store this info in standard Maps (via xbean-finder), then we can just clear the maps and release the memory once it's not needed anymore
LieGrue,
strub
[1] https://github.com/struberg/Apache-commons-classscanner
----- Original Message -----
> From: Romain Manni-Bucau <rm...@gmail.com>
> To: dev@openejb.apache.org
> Cc:
> Sent: Thursday, October 20, 2011 10:43 PM
> Subject: openejb jrat
>
> Hi,
>
> following the start up time of openejb i wondered where we were loosing time
> exactly (even if scanning seems to be a good candidate),
>
> to have results just extract the zip, run start.sh (or something similar,
> there is only one line in the script ;)) and when the window is opened open
> the file openejb.jrat). Then go to hierarchy tab and you'll...that 60% of
> the startup time is due to scanning.
>
> here are the info: http://people.apache.org/~rmannibucau/jrat.output.zip
>
>
> - Romain
>