I was using xCP 16.4 for a long time and was taking the compilation slowness as granted, but recently I had to switch to xCP 2.3 and I noticed something: a project of a similar complexity compiles times faster there. However, if I change the bundled jre from JDK7 to JDK8 the compilation time multiplies by 6. (I also had to replace "PermSize" with "MetaspaceSize" in xcpdesigner.ini, but truly that doesn't change things much).
xCP 16.4 already comes with bundled JDK8. See?
I profiled compilation in xCP 2.3 under both JREs and the most outstanding difference in the hot points is the usage of HashMap called from DataModelPersistanceServiceManager.DataModelKey.equals(). It really looks like 100% of times the instances of that class in the map have a hash collision. And after searching the web I see many examples how improper calculation of hash code led to significant performance drop after switching to java 8.
The profiling tools are something new to me. I still need to recheck this to be sure. The workaround might be to use a custom implementation of HashMap in an endorsed jar. That implementation could handle hash collisions in the old way.
Now I don't know, maybe it's already fixed in DataModelPersistanceServiceManager in xCP 20+, but I don't have it unfortunately.
