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 _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
