From my profiling, the checksum calculation isn’t excessively expensive, the majority of time is spent in the actual database interaction. If you are seeing Class.getGenericInterfaces as the most expensive portion it sounds like the checksum calculation isn’t the expensive part either.
I saw some performance issues with tests running on Linux in the reflection code, but that was resolved by changing the mock object usage. You may be running into something similar, we do use a lot of reflection at times.
Could you send me the profiling information you are getting? If you would prefer, you can email it to me at nathan.voxland@liquibase.org
Nathan
Hi all,
We have a LOT of changesets and we use 1.6.0_51 on Macs.
The time Liquibase spends calculating changesets is too much. It’s already putting people off about using it, making operations use custom tools to extract patches, etc.
I profiled liquibase 3.0.6 and 2.0.3 and found that a lot of time was being spent on the native method:
java.lang.Class#getGenericInterfaces
…which might suggest there’s a problem with our specific platform.
Hi Norman,
I agree with your first points.
I tried with newer jvm and liquibase-maven-plugin versions. Only the latter had any effect, on a 1.7 jvm.
In fact it is taking a lot less time. I guess we’ll just try to upgrade the plugin, stepping through some issues we already found. You’ll probably hear from me in a few days. 
If you’re still interested in the profiler snapshots, I can send them to you.
Cheers,
Vasco
(edited)
If you have some profiler snapshots, that would be great. I also did some improvements to how large tags are handled for 3.0.7, is that something you have in your setup?
I attached a build to https://liquibase.jira.com/browse/CORE-1509 that may help as well, if you wanted to give that a try.
Nathan
