Description of problem: I upgraded my laptop to fedora 9, with the live installation + addition of some packages, like openoffice.org. Office applications are *much* slower than in fedora 8, most visible in import function of office base and query data connection in office calc. Version-Release number of selected component (if applicable): openoffice.org-base-2.4.0-12.8.fc9.i386 How reproducible: Importing medium sized spreadsheet (300k, 2200 rows) into base takes approximately 8 minutes on my system, while it used to be only 15 seconds with the same hardware. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Is it possible that some of the non-native java code is used in the import task (clipboard copy from calc) of the base? The performance impact seems huge. 8 minutes compared to 15 seconds can't be explained by the evolutionary performance impact expected from the new release.
Didn't hear any complaints during the entire devel cycle. Assuming that it is a hsqldb database that base is backing to, what's your java in F-9, i.e. what's selected in in tools->options->openoffice.org->java ?
It seems that the problem actually is in Java. I installed Sun's 1.6.0 JRE and the performance went through the roof. Selected default was gcj from java-1.5.0-gcj-1.5.0.0-21.fc9.i386. I'll post another comments if I find more problems. I would like to find the root cause of this, but I just don't have the time right now.
You installed the "sun jre", I assume here you mean openjdk as provided in fedora ? or do you mean direct from sun.com ? The question seems now to be if a) java-1.5.0-gcj performance has changed since F-8 b) or you had another e.g. icedtea java installed on F-8 and the comparisons were between two different jres
I installed Sun's JRE, directly from sun.com. I'll try with icedtea tomorrow. As for the a,b options, I can't say for sure. I did play with icedtea for a while, but I never changed the java settings in the openoffice manually, and I am pretty sure that I removed icedtea afterwards. Unfortunately, I can't be completely sure, since I upgraded my laptop to F-9 and all the logs are lost.
OOo autodetects java on first start and then sticks with that one unless it disappears in whch case it re-autodetects it and sticks with that version unless it disappears. It prefers ones by the "sun" vendor over others at autodetect time. So if e.g. icedtea/openjdk and gcj are installed and java is used in OOo for the first time it will use the sun one. But if gcj is the only one, then it sticks with that. So if icedtea was not installed on F-8 originally then OOo base was used for the first time then it would have selected gcj and remained at that even after icedtea was installed. But would have used icedtea if it was available and base had not been used before. So its hard to tell what java your OOo was using on F-8, but the odds are that it was using gcj. I'm loathe to just lazily push this bug to gcj, but I don't think that there is anything about OOo that triggers this apparent showdown. I believe that either gcj has slowed down, or gcj was just as slow in F-8 and OOo was using a different jre.
I see that OOo uses at least bsh, xalan and xerces (from requires). Is there a way to figure out if gcj is using .so or .jar for particular invocation? This would certainly cause huge performance impact. Last time I looked, gcj didn't contain JIT. Granted it was a few years ago, but since the strategy was to do native compilations in .so, JIT wasn't needed, and I wouldn't expect it to have one now.
I tried some tests comparing F8 java-1.7.0-icedtea with F9 java-1.6.0-openjdk. First testing with an applet benchmark on F8 and F9 live CDs failed as F8 live CD has problems with the Firefox plugin for applets. Tests with P4 2.4GHz machines and fedora hard-disk installs suggest that if anything, F9 openjdk may be a little faster for the benchmark: http://www.javaworld.com/javaworld/jw-04-1997/jw-04-optimize.html?page=4 Subjective tests with a GUI Java application show a different story. JOSM, a Java-based CAD application for mapping runs like a cow on F9. http://wiki.openstreetmap.org/index.php/JOSM The F8 GUI is snappy, with many frames per second screen updates. On F9, the same jar runs horribly slowly- subjectively an order of magnitude slower. Unfortunately, I can't find a standalone non-applet benchmark mixing GUI and general calculation to give qualitative measures on F8 and F9 live CD to aid testing. Could the OOo database be posted on-line and the import timed on a F8 and F9 live CDs to give some repeatable measures?
Unfortunately, the database I was using contains confidential data. However, you may be able to use any sufficiently big spreadsheet, and copy it to a table using clipboard. My sheet had 15 columns, most of them text with up to 100 characters in length, one integer and one decimal. Last version had 2500 rows. Actual import step is something that can be visibly measured (15 seconds compared to 8 minutes).
Should this bug be changed to NEED_INFO ? or can i move it to ASSIGNED temproarily and is the component Java correct? Cheers Balaji
Someone needs to debug hsqldb backend with gcj, to find the reason for the slowdown. My guess is that the problem lies in some of the used java packages that are interpreted from JARs instead of dynamically linked from SOs (which would explain >30x slowdown). I checked all installed java packages, and they do seem to contain an so for every jar installed, which leads me to believe that the problem is a bit more complicated than I initially thought. The workaround is available, just use java with JIT - e.g. from openjdk or sun. However, default fedora installation brings only gcj, which means that most of the users will be affected.
I ll change the Status to ASSIGNED as of now. Cheers, Balaji
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.