Re: [HELP] fdo#51239 how to debug "it is slow"

On 07/18/2012 10:06 AM, Lionel Elie Mamane wrote:
> The issue *originally* reported in fdo#51239, which has been bumped to
> fdo#52170: in LibreOffice 3.5.2, much slower than "before", on
> GNU/Linux, but NOT on Windows. Unknown on Mac. Not entirely clear what
> "before" it is. *This* issue *could* be JVM-thread-attach/detach
> related, or some other "interaction between Java and C++" problem. My
> "hunch" in this direction is because it does not happen on MS Windows.
> So if you could look into it, even if only to rule it out, that would
> be useful.

Looked into it on x64 Linux master, against both an 1.7.0 openjdk (as 
included in Fedora 17) and a jre-6u33-linux-x64 downloaded from Oracle. 
 In either case, it does take significantly to open the Sales Invoices 
table (from <https://bugs.freedesktop.org/attachment.cgi?id=63257>), and 
then it takes ages to jump to the end.  However, I could not find 
anything obviously suspicious at the JVM level.

I locally reverted 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb59742bcf4883af5876a2ffadcc4a689e414b60> 
"Confine JDBC driver to thread-affine apartment for Java 6 performance" 
and then everything became even more slow, so it apparently is not the 
case that the effect of that fix has meanwhile regressed again.

I noticed that there are truckloads of calls to 
m_pVm->AttachCurrentThread from jvmaccess::VirtualMachine::attachThread 
(jvmaccess/source/virtualmachine.cxx).  Such "outermost" calls into JNI 
(i.e., not recursively from a thread that is already in a JNI call, 
where jvmaccess::VirtualMachine::attachThread would be cheap) are always 
expensive (and the changes to the JVM that we tried to address with 
bb59742bcf4883af5876a2ffadcc4a689e414b60 only made them extra-extra 
expensive, when they already had been expensive).  The LO database code 
is notorious for making truckloads of such expensive outermost JNI 
calls, but I do not know if this has increased substantially recently 
and so alone could explain any recent performance regressions.

Stephan