Created attachment 14551 [details]
Test file

I can't confirm the figures on my system. On my SuSE 8.1 system, OOo 1.1.1 runs
remarkably faster than 1.1.0. The difference might be due to the bad caching of
the Celeron processor on you OOo 1.1.1 system compared to the Pentium-something
on your OOo 1.1.0 system.

Two different processors were only used for the first test on WinXP. All others
were run on identical hardware, including that with the confidential file. I
didn't repeat the test with the test file on my WinXP system because I have
trouble running OOo 1.1 and 1.1.1 in parallel. If absolutely necessary I could
do it. But the result with the confidential file and identical hardware shows
the same picture.

I have tried your test file again on a Pentium 3 1200 MHz,256 MB, SuSE 8.1. On
this machine, some figures are like yours, but still some actions are faster,
e.g. the "Save as" step only takes about 105s.

Did the tests with the Test file on a Power Mac G4 Dual 1.42Ghz with Mac OS X
10.3.3 and Xfree86 4.3.99.16 running a self compiled OOo 1.1.1 and I cannot
confirm this behaviours in full only the Saving as and printing are comparabel
slow to the times of khbellgraf.

My times are:
                                    1.1.1
Action                              MacOSX  
-------------------------------------------
Load document                       35s    
10x scroll down (start at p. 7,      7s    
            as fast as possible)
again 10x scroll down                6s     
20x scroll up                        11s     
Save document as                    60s    
Print to file                       90s   

If I take a postscript capable printer the print to file time is reduced to 74s. 

In my opinion testing must use same machine to get real comparisson. 
Intel pentium 4 is much faster compared to celeron at same speed, because more 
cache. 

everything must same: same OS, same other software installed, same meachine, 
same defragment conditions, etc. 
without this we cannot compare with correct. 
and also some people on user list reported 1.1.1 is faster than 1.1. you need 
to discuss in list, maybe somebody have same experience as yours. 

if you want faster OOo maybe you also need to test OOo 680. bt it still not 
totally fast enaough as the final target(some issue still not yet finish) 

Yes, I agree, all test must be run on identical hardware, and they were for the
Intel platform with only one exception (see my comment from Fri Apr 16 07:52:23
-0700 2004), where an aditional test with the testing file was run on different
platforms, but the results were in agreement with a test on identical hardware
using a confidential file. 

The different behaviours of OOo1.1 and OOo1.1.1 is obvious: you only need to
look at the harddisk activity indicator lamp. For OOo 1.1.1 it flashes for a
long time with high frequency for many editing actions, because quite a high
number of small temporary files is generated.

We have discussed this on the german user list. There were several reports from
people who had the same experience as me. They returned to OOo1.1 at once,
because you cannot work smoothly on the new version when you have man imbedded
objects. Of course, the slow down depends greatly on the document. The
difference in speed is smaller, if you have documents with only a few objects or
only linked graphis. 

The only reports that said OOo1.1.1 is not slower came from two Linux versions .
and Mac OsX. But in these reports no direct comparison to the old version was done.

For time measuring it can be an advantage to use some slow hardware. On my
machine (Atlon AMD K7 Prozessor, 553MHz, 512MB RAM Windows XP Professional
Version 2002 Service Pack 1) I found the following results:

                            OOo     680m34    1.1.1     1.1.0
Action                              WinXP     WinXP     WinXP
----------------------------------------------------------------
Start whith an empty document        32s       11s       22s
(on a fresh rebooted system)
Load document and wait until        289s      287s     >780s (*)
the end of harddisk activity
10x scroll page down                 11s       12s        6s
(start at page 3, wait on every
page until it has build up)
scroll 10x page down again           19s       16s       12s
scroll 20x page up                   26s       23s       16s
"Save as"                           210s      216s      105s
Print in a file                     280s      297s      190s

(*) In OOo1.1.0, the document is ready to be worked on it much faster than in
the newer OOo1.1.1 and OOo680. But the hardisk activity doesn't stop, but
silently goes on without disturbing the work on the document.

*** Issue 27876 has been confirmed by votes. ***

I repeated the measurement of the time that OOo1.1.0 uses to load the test
document in the attachement of this issue. Now I fist observed the normal hard
disk activity without OOo, then openend OOo, loaded the document, and waited
until the harddisk behaved normal again. Now the result is even more clear:

                            OOo     680m34    1.1.1     1.1.0
Aktion                              WinXP     WinXP     WinXP
----------------------------------------------------------------
Dokument laden (*)                  289s      287s       70s

MRU->TL: there is a heavy performance loss from from OO 1.1.0 to newer versions.
The attached document illustrates this well. It needs almost the double time
when opening now. Also when working with the document, there's a heavy loss of
performance. When scrolling through the document, you can see that there's heavy
harddisk activity and it needs more time to paint the objects on the screen.
A quick investigation / debugging session on this would be great, just know
about the effort/risk on a fix for this (and also if you are the correct owner).

I don't think the performance loss comes only from math formulas. Of course, in
the test document there are much more formulas than draw objects. But my
impression is, that the buildup of draw objects itself is also much slower and
this affects significantly the speed of scrolling as well.

(FYI: performance problems with formulas in combination with glyph-fallback,
large fonts and unpatched X-Server: see issue 27259)

TL->HDU: Can you please check if this is also a problem of the glyph fallback?
Thanks!

Added myself to CC list.

.

The problem exists not only with big documents but also with 1-page-letters.
Even writing is dificult, the characters drop one by one over the screen.
We are working with a linux-server by XDMCP (4GB Server-RAM, that are shared
among 20 users). 
We're running a test with only 2 users who work with the version 1.1.1. All the
rest works with version 1.0.2 and do not suffer any performance problems.

I can confirm that problem with 1.1.1  WIN XP: [645m35(Build8762)], without
being able to tell much new information. I compared a.m. version with
1.1.0 German version WIN XP: 645m19(Build8693) on an Athlon  3200+, 512MB RAM,
all tests with attached "Test.sxw":

                                      1.1.0                       1.1.1           
Load time with already started OOo     15s                        240s
Memory consumption                     57MB                        97MB (rising 
                                                                   during load 
                                                                   time)
Save as                                48s                        190s

I can confirm the excessive harddisk access.

Rainer

utomo > lib:
Please add more data regarding your one page documents test. is this happend 
with specific documents or with any documents ? please attach your documents, 
so we can test it.
and is the regression is happend with local OOo too?. 

If the Regression is happenned with most documents (not only with many math 
objects) & local OOo, we maybe need to consider this and maybe better to delay 
1.1.2 if needed. I think little bit delay is better than got user bad 
regression experience.
And maybe we have Framework Regression instead of Writer regression here. 
Thanks.

Added myself to CC

The problem seems to be that the performance with OLE objects dropped between
these two releases.
HDU->FME: Reassigning the issue to you as discussed with you and MBA.

HDU->TL: There are some strange characters in there: U+02D9 and U+2212
On systems where OpenSymbol/StarSymbol are not visible to OOo these unicodes
will cause glyph fallback, but I don't think this causes any of the problems here.

Re-targeted to OO 1.1.2.

FME->MBA: As discussed, it looks like there are tons of tmp files generated.
Could you please have a look?

The performance was hit by another bugfix: because we didn't recognize when
writing a file failed due to a full hard disc, we now always force a stream to
be written to disc when it is closed - so we can catch any occuring error.

This means that in the current case where more than 2000 streams are created, a
lot of time was spent in closing streams. So I optimized the implementation
reading streams from packages that they never create stream buffers if not
explicitly requested, so the loading speed now reached the old performance level
(and possibly is even a bit faster if large streams are involved).

Unfortunately I can't apply this fix to the writing case, so there is only a
small performance gain here. Here the old speed is available only at the cost of
a higher risk of data loss, and I'm not willing to do this. We must reorganize
the way we handle temporary stream objects (try to represent them by only one or
a few real streams on disc), but this can't be done ATM. 

We will fix this for OOo2.0 and possibly for OOo1.1.3 (depending on the risk we
detect in the OOo2.0 implementation).

The bad scrolling performance is not a bug. It is a result of the fact that we
made the OLE cache working at all - it just didn't work in OOo1.1 and OLE
objects where never removed from memory, not per default only 20 of them are
kept in memory, thus forcing us to reload objects when necessary. If users find
this inconvenient they should enlarge the buffer for OLE objects in
"Tools-Options-Memory".

I set the status to "fixed" for this target, but we should reopen it as soon as
it has been verified and assign a new target for it.

.

Verified in CWS pp3regression1.
I could see a gain of performance by about 50%when opening the document. More
improvements won't be done for OO 1.1.x, as mba's arguments clearly pointed out.

MRU->MBA: I think we should create a complete new (clone?) task, where the rest
of the fix for OO 2.0 should be done.

*** Issue 26420 has been marked as a duplicate of this issue. ***

I  created a new clones task (#30190) for OOo2.0.