Created attachment 467759 [details] simple database with one table with 500 records Description of problem:Very slow database operations Version-Release number of selected component (if applicable):openoffice.org-base-3.3.0-17.2.fc14.i686 (OOO330m17) How reproducible:every time Steps to Reproduce:open a database table, seek to end, notice time used 1. 2. 3. Actual results: Expected results: Additional info: When I open a database file from f-12 system which I think is OOO320, it runs VERY slow. It takes nearly 60 seconds to access record 121 (the end) of a small table. Other operations, like mail merge exhibit slowness too. CPU usage during this time is 100%. 32 bit version f-14 running on Acer Travelmate 7320 with 2GB RAM. Reasonably fast processor. Tried copying to new table in same database - same performance. Tried copying to new table in new database - same performance. Tried exporting to spreadsheet and then re-importing - same performance. Tried creating simple spreadsheet 18 columns x 500 rows. First cell has ascending integer. Then imported to database table with a primary key. Time to open first page of 33 records: 12 seconds. Time to seek to last record using "end" button: 48 seconds. I have attached this test database file. I have previously reported this to openoffice.org. They have not been able to reproduce it and have instructed me to report it here.
caolanm->sbergman: can you see if this still seems to affect current fedora or if it was fixed by the context-foo I seem to recall you mentioning in relation to java stuff. And/or if we know its java's fault throw it over the wall to that team to have a look at
This is known upstream as <https://bugs.freedesktop.org/show_bug.cgi?id=35023> "FILEOPEN Base functions extremely slowly with Java 1.6.0_20 and >1.6.0_24." (For details, see esp. the 12th comment there and the referenced mail thread at <http://nabble.documentfoundation.org/Trying-to-diagnose-base-running-extremely-slowly-tt3426499.html#a3436909>.) It is an unfortunate combination of JNI Attach/DetachCurrentThread having become significantly more expensive in recent Java versions and the LO Base code calling those JNI functions very frequently.
caolanm->sbergmann: do you know if its base that's calling Attach/DetachCurrentThread a lot or if its hsqldb itself ?
caolanm->aph: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 seems to trigger http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024514 which is basically this bug. Any cunning ideas ?
The fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 introduced another issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6978641 So we basically need to backport these 2: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3b3d12e645e7 http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/9b2e416eda7f Andrew, do you see any issues with backporting the above (you reviewed the latter)? If not, I can propose a backport to the hotspot list.
These fixes won't necessarily fix the real problem. If someone can come up with an actual reproducible test case I'll have a look. But it has to be better than "Just create a SQL table with more than 100 rows", it has to be something I can do.
reproducible test case: with libreoffice-base package installed, call soffice with the attached New Database1.odb, select "Tables" in the left pane, double-click "Table 1" in the lower right pane, new window opens, click the little "go to end" button at the bottom of the window (left of the horizontal scroll bar, there are buttons with "go to beginning," "previous," "next," "go to end" icons): takes multiple seconds
The problem is here: void SAL_CALL java_sql_PreparedStatement::setInt( sal_Int32 parameterIndex, sal_Int32 x ) throw(::com::sun::star::sdbc::SQLException, ::com::sun::star::uno::RuntimeException) { m_aLogger.log( LogLevel::FINER, STR_LOG_INT_PARAMETER, parameterIndex, x ); ::osl::MutexGuard aGuard( m_aMutex ); checkDisposed(java_sql_Statement_BASE::rBHelper.bDisposed); SDBThreadAttach t; OSL_ENSURE(t.pEnv,"Java Enviroment geloescht worden!"); ^^^ Note that for every setInt, the thread is attached and then detached. This makes no sense at all. You need a parameter that keeps track of whether a thread is attached or not. Either that, or dedicate a separate thread to the Java database access. There is nothing much that can be done to make jni_{Attach,Detach}CurrentThread super-fast; it needs to be used less often. createStatement(t.pEnv); static jmethodID mID(NULL); callVoidMethod("setInt", "(II)V", mID, parameterIndex, x); }
Thanks Andrew for confirming that the LO code needs fixing. The original developer always claimed this was hard to do. Will have to have a look into this.
There is an alternative: attach the thread and leave it attached. You'll have to make sure that the Java stack limit is large enough to accommodate the maximum extent to which the stack may ever grow.
will be fixed in >=libreoffice-3.4.4.2-8.fc16 (backporting fix for upstream <https://bugs.freedesktop.org/show_bug.cgi?id=35023> "FILEOPEN Base functions extremely slowly with Java 1.6.0_20 and >1.6.0_24")
libreoffice-3.4.5.2-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libreoffice-3.4.5.2-1.fc16
Package libreoffice-3.4.5.2-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreoffice-3.4.5.2-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0914/libreoffice-3.4.5.2-1.fc16 then log in and leave karma (feedback).
libreoffice-3.4.5.2-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.