Birt performance problems and solutions

Today, my colleague has a Birt performance problem that needs to be solved. This problem is embedded in a section of Birt that we wrote by ourselves. Code To call some existing classes to obtain the database information in the configuration file. Because the database username and password are encrypted, they cannot be directly written in the rptdesign file, instead, you can only obtain database information by calling the existing classes. Every time this class is called, it will lead to a particularly slow report generation by BIRT, And the CPU remains high. If you do not call these classes, the same query conditions and the same data, the same database will return quickly, with a difference of 25-30 times.
To solve this problem, we first think of Birt as an embedded Javascript statement in the rptdesign file. Will Birt reload the classes we use? So we added a static domain in those classes and added some logs to the static domain and constructor. But the result is that the static domain is executed only once, that is, those classes are not repeatedly loaded. This idea is incorrect.
Then I thought that every time the CPU consumption was very high, so I used jvisualvm of JDK 6 to profile, so I switched the environment to JDK 6 and started to profile CPU information, the results show that the CPU usage is not Birt or our own class, but some system classes. This idea is also ruled out because only such information is specific.
Finally, we thought about whether we could dump the thread information when the CPU was very busy. So we dumped a lot of data and began to analyze the thread information. This is why we found that when the CPU is very busy, there is always a thread (that is, the thread where the Birt in Tomcat generates reports), which is especially because it only has a particularly long stack information, it can be seen at a glance that it is related to BIRT's JavaScript library. In addition, although the top stack does not stay in the same position, there is a Mozilla JavaScript importpackage method in the middle of the stack. So I found the rptdesign file and found importpackage (packages. x. y. z); check whether there is a problem with importpackage here, So I deleted this sentence, and then used the full path of the class during the next call. Try again, sure enough, the problem is gone.
But the reason is not clear. Wait and try again.
Conclusion: thanks to God, I am lucky enough to handle it accidentally.