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

[Lionel Elie Mamane]

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.

> Looked into it on x64 Linux master (...)

Thanks.

> 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 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)?

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.

Or maybe if we know that we are about to make a truckload of Java
calls from C++, wrap it in a Java trampoline that just calls the C++
function that will make many Java calls? So that we are in the
"recursive" case? Hmm... that could be hackish, since it would involve
generic code looking at whether it is connecting to the database
engine through JDBC (Java) or some other way.

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?

-- 
Lionel