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.
