After running my xstream serialization/deserialization through a profiler (YourKit), I found that PureJavaReflectionProvider.fieldDefinedInClass is taking up nearly 30% of the CPU time. This is because it calls FieldDictionary.field to check if a field exists. If the field does not exist, FieldDictionary.field throws an ObjectAccessException instead of returning null. Unfortunately, throwing exceptions is an inherently expensive operation in the JVM, and PureJavaReflectionProvider.fieldDefinedInClass is called very frequently. The more performant solution would be to have FieldDictionary.field return null, and handle the null-checking at the appropriate call sites. If this is an exposed API method, an alternative solution would be to make a second method which does not throw the exception.
Hi Keith, I added now a new method - simply because there are quite some other calls to FieldDictionary.field that expect a valid object or an exception. However, in case of PureJavaReflectionProvider.fieldDefinedInClass you are absolutely right, it was really superfluous. Changes applied in the head revision. Thanks for taking your time with YourKit.
Here's a patch fixing the basic issue. Since FieldDictionary seems to be an exposed class, and therefore could be used by external people, I'm not sure if you want to maintain backwards compatibility of the old behavior.