I've prepared benchmarks in one of my test projects, please see https://github.com/stsypanov/spring-data-examples To reproduce do the following: 1. Checkout project 2. Build `mvn clean compile -P no-instrumentation` which will compile classes without enhancing byte code 3. Run `main` method of BenchmarkRunner.java 4. Rebuild with `mvn clean compile -P no-instrumentation` which will compile classes and enhance byte code 5. Again run `main` method of BenchmarkRunner.java This benchmark measures average time needed to execute saveAndFlush() taking dirty entity as argument. The entity itself has 10 string fields but only one of them is modified. When we use conventional approach (no enhancement) Hibernate takes entity's snapshot and compares all the fields with those of dirty entity. This makes up 10 comparisons executed in a loop in org.hibernate.type.TypeHelper#findDirty. On the contrary with the new approach field comparison occurs when field's setter called i. e. before saveAndFlush(). Benchmark shows the second approach is slower. For the first case I've got
Result "com.luxoft.logeek.benchmark.ByteCodeInstrumentationBenchmarkForSingleEntity.measureDirtyChecking":
174,005 ±(99.9%) 3,651 us/op [Average]
(min, avg, max) = (167,726, 174,005, 235,167), stdev = 10,766
CI (99.9%): [170,354, 177,657] (assumes normal distribution)
# Run complete. Total time: 00:01:53
Benchmark Mode Cnt Score Error Units
ByteCodeInstrumentationBenchmarkForSingleEntity.measureDirtyChecking avgt 100 174,005 ± 3,651 us/op
and for the second
Result "com.luxoft.logeek.benchmark.ByteCodeInstrumentationBenchmarkForSingleEntity.measureDirtyChecking":
181,544 ±(99.9%) 2,280 us/op [Average]
(min, avg, max) = (176,103, 181,544, 223,023), stdev = 6,724
CI (99.9%): [179,263, 183,824] (assumes normal distribution)
# Run complete. Total time: 00:01:53
Benchmark Mode Cnt Score Error Units
ByteCodeInstrumentationBenchmarkForSingleEntity.measureDirtyChecking avgt 100 181,544 ± 2,280 us/op
There's also a bechmark for list of entities with size 10, 100, 1000, 10000. To run it just uncomment corresponding line in `BenchmarkRunner` I'm not completely sure my measuring is correct. Maybe you are right and the reason for degradation is different. |