Bug 446318

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.