[fedora-java] OOo Performance?

[Andrew Haley]

Mark Wielaard writes:
 > On Wed, 2006-03-15 at 20:44 +0000, Caolan McNamara wrote:
 > > On Wed, 2006-03-15 at 13:06 -0500, Andrew Overholt wrote:
 > > > Is this true:
 > > > 
 > > >  "In OpenOffice.org, for instance, Java-based features such as the basic
 > > >  document wizards open so slowly that you may conclude that the program has
 > > >  frozen before anything happens."
 > > > 
 > > > ?
 > > > 
 > > > http://www.linux.com/article.pl?sid=06/03/08/2321254

I wonder what sort of machine he was using.

 > > 
 > > To test this wizard start-up time: File->wizards->letter.
 > 
 > The first time you use an wizard is indeed pretty slow, it sits there
 > eating up 100% CPU for a couple of seconds (at least on my
 > Debian/unstable box, I cannot get ooffice from FC5/rawhide to work
 > unfortunately. It seems stuck in the splash screen according to gdb
 > somewhere in reading the font cache). But after that using the wizards
 > works just fine.
 > 
 > What was the magic oprofile incantation again to get a useful report
 > about what is happening on the system?

Here you are:

samples  cum. samples  %        cum. %     image name               app name                 symbol name
26745    26745         22.6147  22.6147    ld-2.3.90.so             ld-2.3.90.so             do_lookup_x
19998    46743         16.9096  39.5243    no-vmlinux               no-vmlinux               (no symbols)
12112    58855         10.2415  49.7658    ld-2.3.90.so             ld-2.3.90.so             strcmp
6050     64905          5.1157  54.8815    libuno_cppuhelpergcc3.so.3 libuno_cppuhelpergcc3.so.3 (no symbols)
5395     70300          4.5618  59.4433    libgcj.so.7.0.0          libgcj.so.7.0.0          GC_mark_from
5232     75532          4.4240  63.8673    libuno_sal.so.3          libuno_sal.so.3          (no symbols)
2224     77756          1.8805  65.7478    configmgr2.uno.so        configmgr2.uno.so        (no symbols)
1663     79419          1.4062  67.1540    libgcj.so.7.0.0          libgcj.so.7.0.0          GC_add_to_black_list_normal
1567     80986          1.3250  68.4790    libuno_cppu.so.3         libuno_cppu.so.3         (no symbols)
1444     82430          1.2210  69.7000    libtk680li.so            libtk680li.so            (no symbols)
1267     83697          1.0713  70.7713    libgcj.so.7.0.0          libgcj.so.7.0.0          __i686.get_pc_thunk.bx
1158     84855          0.9792  71.7505    libpthread-2.3.90.so     libpthread-2.3.90.so     pthread_mutex_lock
1081     85936          0.9141  72.6645    libvcl680li.so           libvcl680li.so           (no symbols)
1066     87002          0.9014  73.5659    libcrypto.so.0.9.8a      libcrypto.so.0.9.8a      (no symbols)
1019     88021          0.8616  74.4276    libpthread-2.3.90.so     libpthread-2.3.90.so     pthread_mutex_unlock
876      88897          0.7407  75.1683    libgcj.so.7.0.0          libgcj.so.7.0.0          _Jv_InterpMethod::run(void*, ffi_raw*, _Jv_InterpMethod*)
849      89746          0.7179  75.8862    libgcj.so.7.0.0          libgcj.so.7.0.0          .plt
829      90575          0.7010  76.5871    libgcj.so.7.0.0          libgcj.so.7.0.0          GC_find_start
741      91316          0.6266  77.2137    libgcc_s-4.1.0-20060304.so.1 libgcc_s-4.1.0-20060304.so.1 _Unwind_IteratePhdrCallback
643      91959          0.5437  77.7574    libsw680li.so            libsw680li.so            (no symbols)
634      92593          0.5361  78.2935    libgcc_s-4.1.0-20060304.so.1 libgcc_s-4.1.0-20060304.so.1 execute_cfa_program

So, this is caused by the dynamic loading of the libgcj runtime
environment, which is why it takes a long time the first time you use
it.  

After that, however, it seems reasonably quick.

This speed will be much improved once we get rid of some of the relocs
in libgcj.

Andrew.