incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 120124] optimize graphic cache to improve odt saving performance
Date Tue, 17 Jul 2012 08:03:50 GMT

--- Comment #3 from ---

1.following is test result for sample file sw_complex_100p.odt(manual test),
about 18% improvement.
old: 3.88   3.71   3.79   3.85   3.87   3.78   3.85   3.81   3.91   3.9  
new: 3.15   3.06   3.06   3.35   3.03   3.34   3.12   3.03   3.1   3.03  

2.We can get rid of these comments if unnecessary.

3.We set graphic cache to 0x2800000, that is 40M. Choose this value because we
found quanties of .odt sample files don't have graphics exceed 40M.

4.The mnMaxCacheSize can't be configured via Tools->Options. 

5.We need to get used cache size and max cache size in(
sw/source/filter/xml/xmltexte.cxx, lines 229 to 233) and the two values can
accessed by GraphicManager(pGrfNd->GetGrfObj().GetGraphicManager()). The two
values are stored in GraphicCache, but its instantiation is a private member in
GraphicManager, so add two member functions to access them.

6.The cache is 40M, but not 2.8M. When one graphic object is swapped in, its
size is added to mnUsedCacheSize. When .odt document is saved, we need not to
swap not every graphic, we only swap out graphic when  mnUsedCacheSize exceed

for more information, you can refer to

(In reply to comment #2)
> I have several questions and remarks:

- How much faster does saving get
> with this cache?

- There is not much documentation of the new code.  Only
> unnecessary comments that state the issue id, information that is available
> via svn annotate.  Can we get rid of these?

- The mnMaxCacheSize is set to
> an arbitrary magic number of 2800000.  Why this number?

- The
> mnMaxCacheSize value is not coordinated with other caches or configurable
> via Tools->Options

- There are two new methods GetUsedCacheSize2() and
> GetMaxCacheSize2() that just forward the results from their counterparts
> without the ...2 suffix.  Why?

- The actual caching logic seems to be the
> lines in the last hunk of the diff (in sw/source/filter/xml/xmltexte.cxx,
> lines 229 to 233).  They seem to prevent caching of the first created
> objects that fit into the 2.8MB cache.  They will never get swapped in or
> out.  Every object created once the cache is full will always be swapped in
> or out.  That does not look like a good caching strategy and should be
> improved.

You are receiving this mail because:
You are the assignee for the bug.

View raw message