[HELP] fdo#51239 how to debug "it is slow"
sbergman at redhat.com
Thu Jul 19 05:53:35 PDT 2012
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/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)
> 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
> 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
"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
More information about the LibreOffice