Issue 15411 - VM size grows up when saving a writer document, and ...
Summary: VM size grows up when saving a writer document, and ...
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1 Beta2
Hardware: PC Windows 2000
: P3 Trivial (vote)
Target Milestone: ---
Assignee: h.ilter
QA Contact: issues@sw
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-08 12:35 UTC by quetschke
Modified: 2013-08-07 14:41 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description quetschke 2003-06-08 12:35:41 UTC 
doesn't go down after saving.

This is propably a duplicate of issue 15321, but as it happens for writer
I start a new issue.

The main problem is that *it* keeps the memory after saving. The document I'm
working on contains ~140 pages, ~30 pictures (png, jpg, vektorformat and eps) all
embedded (no links).

Until I save I have a memory usage of ~100MB, which goes up to ~600MB after
saving. (And stays there)

As I only have 512MB real memory, and there are some other programs running
the machine is getting quite slow.

After I close the document and reopen it I'm again down to ~100MB.

vq->cl: You say it is fixed in issue 15321, can you tell me in which
cws... workspace you were working, then I can give it a try if it also
solves my problem.

P.S.: I cannot attach the document, as it's going to be my Ph.D. thesis, but
      if I'm contacted by a developer I'd be happy to send it to him for
      some proofreading. ;-) (Attention german text)
Comment 1 clippka 2003-06-10 08:51:05 UTC 
well it can't be fixed by issue 15321 since the fix was in the API of
the drawing layer graphic object and the writer for historical reasons
use its own. But I think its caused by the same problem. If anyone
from the writer team tries to fix this, please contact me.
Comment 2 h.ilter 2003-06-10 10:51:16 UTC 
HI->VQ: Do you have an URL for me to get the bugdoc?
Comment 3 quetschke 2003-06-11 17:05:33 UTC 
VQ->HI: Did you get my mail with the bugdoc?
Comment 4 h.ilter 2003-06-13 12:51:48 UTC 
HI->FME: Compared with PP3 and I'd say we have an performance
regression here. 
Please have a look to the bugdoc. 
You'll find it under ../hi/issues/Diss_big11.sxw
Comment 5 frank.meies 2003-06-13 14:29:15 UTC 
FME->DVO/MIB: Yes, verified.
Comment 6 openoffice 2003-09-18 17:28:34 UTC 
.
Comment 7 h.ilter 2003-11-13 15:31:21 UTC 
HI: The performance should be increased and not decreased. Set to OOo
1.1.1
Comment 8 stefan.baltzer 2003-12-10 14:51:11 UTC 
SBA->DVO: As discussed with KA, MIB, TZ, the possible side effects make this fix
too risky for OOo 1.1.1 (and SO PPs). Since the submitter told a convenient
workaround (reload the file after saving), this one will be re-targeted to OOo 2.0.
Comment 9 openoffice 2003-12-11 12:47:58 UTC 
dvo: Fixed in sw/source/filter/xml/xmltexte.cxx for swq02.

As indicated by CL, the problem was that during save-as, all graphics in the
file are touched and thus swapped into memory, but nobody swapped them out
again. The patch now swaps those graphics out again.

This has been a touchy area with signigicant breakage in the past; hence nobody
wanted to put the patch into an 1.1.x bugfix. For 2.0, it will now go through
the full beta & testing programs, which makes us feel a lot saved. :-)
Comment 10 openoffice 2004-12-20 18:13:48 UTC 
reopen for QA
Comment 11 openoffice 2004-12-20 18:14:37 UTC 
dvo->hi: Please test on any current CWS.

The issue was fixed in some older CWS, but apparently I failed to properly add
it to said CWS' issue list.
Comment 12 openoffice 2004-12-20 18:14:51 UTC 
set fixed
Comment 13 h.ilter 2005-01-17 16:09:53 UTC 
No increasing of files so far.