I get a signifcant speed regression using the ResourceDatabasePopulator to load database scripts, when I switch from oracle JDK 1.7.0_05 to 1.7.0_06 or _07 on Windows XP SP3. With JDK 1.7.0_05 the script loads in 337ms with 1.7.0_06 or newer it takes over 40000ms to load the same script.
According to my tests the regression is located in the splitSqlScript(script, delimiter, statements) method.
I've debugged it further and the issue seems to be with String.substring(…) called from ResourceDatabasePopulator.splitSqlScript(…) the final bottleneck being Arrays.copyOfRange.
The has been a bug reported against that method for Java versions < 7u06, which was fixed with u06 which might cause the issue as the fix touches that method and was introduced in the version that seems to be the first one with the symptoms the original poster describes.
commit 3fb3b7d67a2a0b6990ad17978877a552d03f7b81
Author: Oliver Gierke <ogierke@vmware.com>
Commit: Chris Beams <cbeams@vmware.com>
Work around JDK7 String#substring performance regression
String#substring has become significantly slower as of JDK 1.7.0_06 [1],
such that there are performance degradations by a factor of 100-1000 in
ResourceDatabasePopulator, especially for large SQL files.
This commit works around this problem by minimizing the substring scope
to the least amount possible to prevent unnecessary internal copying of
strings (which seems to cause the issue).
[1]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010257.html
Issue: SPR-9781
Philipp Hügelmeyer opened SPR-9781 and commented
I get a signifcant speed regression using the
ResourceDatabasePopulator
to load database scripts, when I switch from oracle JDK 1.7.0_05 to 1.7.0_06 or _07 on Windows XP SP3. With JDK 1.7.0_05 the script loads in 337ms with 1.7.0_06 or newer it takes over 40000ms to load the same script.According to my tests the regression is located in the
splitSqlScript(script, delimiter, statements)
method.Affects: 3.1.2
Attachments:
Sub-tasks:
Referenced from: commits ec2df7d, 92a92b7, 86ef22d, 3fb3b7d
The text was updated successfully, but these errors were encountered: