Bug 446318 - Java using openoffice.org-base much slower in fedora 9
Java using openoffice.org-base much slower in fedora 9
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: java-1.5.0-gcj (Show other bugs)
9
All Linux
high Severity medium
: ---
: ---
Assigned To: Lillian Angel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-13 22:47 EDT by Tomislav Vujec
Modified: 2009-07-14 12:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:44:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomislav Vujec 2008-05-13 22:47:48 EDT
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.
Comment 1 Caolan McNamara 2008-05-14 03:01:38 EDT
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 ?
Comment 2 Tomislav Vujec 2008-05-15 02:02:01 EDT
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.
Comment 3 Caolan McNamara 2008-05-15 02:49:31 EDT
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
Comment 4 Tomislav Vujec 2008-05-15 03:07:43 EDT
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.
Comment 5 Caolan McNamara 2008-05-15 03:38:55 EDT
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.
Comment 6 Tomislav Vujec 2008-05-15 04:31:46 EDT
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.
Comment 7 James Derrick 2008-05-25 09:34:50 EDT
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?

Comment 8 Tomislav Vujec 2008-05-25 10:55:10 EDT
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).
Comment 9 Balaji G 2008-06-06 07:42:17 EDT
Should this bug be changed to NEED_INFO ? or can i move it to ASSIGNED
temproarily  and is the component Java correct?

Cheers
Balaji
Comment 10 Tomislav Vujec 2008-06-08 12:15:04 EDT
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.
Comment 11 Balaji G 2008-06-08 12:43:03 EDT
I ll change the Status to ASSIGNED as of now. 

Cheers,
Balaji
Comment 12 Bug Zapper 2009-06-09 20:46:42 EDT
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
Comment 13 Bug Zapper 2009-07-14 12:44:26 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.