Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Bad performance of OOo 1.1.1 with Math objects. Regression | ||||||
---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | khbellgardt <bellgardt> | ||||
Component: | code | Assignee: | Mathias_Bauer | ||||
Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | dg_zm, eric_openoffice, frankgodbersen, hdu, issues, Joost.Andrae, michael.ruess, piotr, rainerbielefeld_ooo_qa, thomas.lange, thorsten.ziehm, utomo.prawiro | ||||
Version: | OOo 1.1.1 | Keywords: | oooqa | ||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
khbellgardt
2004-04-16 09:28:45 UTC
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. |