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

On 07/19/2012 02:38 PM, Lionel Elie Mamane wrote:
> On Thu, Jul 19, 2012 at 02:12:30PM +0200, Stephan Bergmann wrote:
> > 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.
>
> > 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 (...).  The LO database code is notorious for
> > making truckloads of such expensive outermost JNI calls, (...)
>
> Try to give me an idea what would cause such calls. Is it Java code
> calling C(++) code (presumably through UNO) or C(++) code calling Java
> code (again presumably through UNO)?

C++ code in connectivity and/or dbacess calling Java, not through UNO 
but directly talking JNI (though going through UNO would not actually 
make a difference to the performance implications).  Grepping for 
jvmaccess::VirtualMachine::AttachGuard in connectivity and dbaccess 
should show the places where this is done.

> For example, to minimise the number of Java calls from C++ , maybe we
> could, when we retrieve a whole row through JDBC, doing this from Java
> code instead of from C++ code:
>
> for (i=0; i < row->getNumberOfColumns; ++i)
>     cacheEntry[i]=row->getColumnValue(i);
>
> This would bring us down from one call per column to one call per row,
> hopefully without duplicating *too* *much* logic between a C++ version
> and a Java version.

Yes, this could be helpful.  (When I discussed this with Ocke years ago, 
he always claimed there it was not possible to redesign the 
connectivity/dbaccess code to reduce the number of such "outermost" JNI 
calls, though.)

> A breakpoint at jvmaccess::VirtualMachine::attachThread in gdb does
> not seem to be immediately useful; the backtrace does not show me
> where that "comes from". Is there a way to see that?

That might be due to 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb59742bcf4883af5876a2ffadcc4a689e414b60> 
"Confine JDBC driver to thread-affine apartment for Java 6 performance" 
offloading part of the code off the main thread into a dedicated thread. 
 You can try reverting that locally (at the expense of even slower 
performance).

Stephan