[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3909) Improve Performance of FieldInterceptionHandler (and thus of flushing)

[Ovidio Mallo (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33172#action_33172 ] 

Ovidio Mallo commented on HHH-3909:
-----------------------------------

I'm using the trunk version of Hibernate and the warning which is being output is in InstrumentTest#runTest() which checks whether the classes in the org.hibernate.test.instrument.domain package are instrumented. I will have a closer look at why it doesn't work for me since I do also have CGLib and JavaAssist in the classpath.

In any case, I guess you're right in that my patch is not really correct since Class#getInterfaces() does only return the interfaces declared on the actual class but not any interfaces implemented by superclasses as I was assuming. In that case, using "instanceof" as I'm doing in my patch is obviously not the same thing.

In general, Class#getInterfaces() is probably the right thing since otherwise you might do the dirty checking on a class which is not itself instrumented but only one of its superclasses. So I guess you can discard my patch. I'm sorry for not having catched this up earlier.

> Improve Performance of FieldInterceptionHandler (and thus of flushing)
> ----------------------------------------------------------------------
>
>                 Key: HHH-3909
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3909
>             Project: Hibernate Core
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.3.1
>            Reporter: Ovidio Mallo
>         Attachments: patch.txt
>
>
> In the FieldInterceptionHelper class, the method Class#getInterfaces() is used in conjunction with a subsequent loop over all interfaces of an entity class in order to check whether a bytecode instrumentation interface of CGlib or Javassist is found. This is done that way since CGlib and Javassist are both optional so they should only be accessed at runtime if available on the classpath. Attached you can find a simple patch which only once checks whether CGlib and/or Javassist is available and then uses the more performant "instanceof" operator in order to check whether an entity has an interceptor. The new code still guarantees that no CGlib or Javassist class is accessed if it is not on the classpath.
> The patch helps making the FieldInterceptionHelper methods more performant which can e.g. be noticed during a session flush, especially if bytecode instrumentation is used. In order to measure the performance impact of the patch I've written a simple program which does the following:
> 1. insert 100 thousand entities into a simple table with 6 numeric attributes
> 2. do an initial flush on the session in order to execute all the insert statements
> 3. loop 300 times and do a flush on the session (only a dirty check is performed, no database operation)
> I've time the flushes under point 3 above with and without bytecode instrumentation for the used entity. Here are the results:
> USING BYTECODE INSTRUMENTATION
> =============================
> * SUN JVM 1.6.0_05:
>   - without patch:  25734ms
>   - with patch:     11015ms
> * IBM JVM 1.4.2:
>   - without patch:  20672ms
>   - with patch:     11140ms
> WITHOUT BYTECODE INSTRUMENTATION
> ================================
> * SUN JVM 1.6.0_05:
>   - without patch:  73328ms
>   - with patch:     62015ms
> * IBM JVM 1.4.2:
>   - without patch:  70344ms
>   - with patch:     61125ms
> Using bytecode instrumentation, the performance improvement is about of a factor of 2-2.5. When not using bytecode instrumentation, the overall impact is of course less relevant since the rest of the work done during flush is more expensive anyway. In any case, IMHO the impact when using bytecode instrumentation is relevant.
> The patch is very simple and only touches the FieldInterceptionHelper class.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira