[jboss-dev] Improving scanning performance
Jason T. Greene
jason.greene at redhat.com
Tue Jun 16 17:00:03 EDT 2009
Scott Marlow wrote:
> Ales Justin wrote:
>> All of this already exists. ;-)
>>
>>> * You should have a AnnotationScanner deployer that scans jars for
>>> annotations and puts an annotation database somewhere in memory that
>>> other deployers can reference. (This might already exist, I don't
>>> know).
>>
>> It is called AnnotationEnvironment, and it's part of the deployment's
>> attachments.
>>
>> It's already used to help Metadata get annotation info.
>> But how it's done in Metadata is bad/wrong.
>>
>>> * If a file META-INF/no.scan exists in a jar, then don't scan the
>>> file. This allows libraries to exclude themselves from scanning.
>>>
>>> * If a file META-INF/scan.only exists it will contain a newline
>>> delimited list of class names to scan. Only scan those class names.
>>
>> This is called jboss-scanning.xml.
>> - http://www.jboss.org/community/wiki/JBoss5custommetadatafiles
> I hacked my local trunk (6) build to use jboss-scanning.xml and don't
> see much of an impact on boot performance. Prior to the
> jboss-scanning.xml changes, we were scanning about 600 classes for
> annotations. After the changes, we scan zero classes for annotations
> (as per trace logging in o.j.d.p.a.GenericAnnotationResourceVisitor).
> My local timings are:
Interesting findings. Although keep in mind we have a few other paths
where scanning occurs, usually post-classloading. Anything that uses the
MDR for example (AOP is one example)
--
Jason T. Greene
JBoss, a division of Red Hat
More information about the jboss-development
mailing list