To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=66680
                 Issue #|66680
                 Summary|shrink ImageList memory usage ...
               Component|gsl
                 Version|680m174
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|PATCH
                Priority|P3
            Subcomponent|code
             Assigned to|ka
             Reported by|mmeeks





------- Additional comments from [EMAIL PROTECTED] Fri Jun 23 02:25:45 -0700 
2006 -------
So - this patch is several things:

   1st: binning a chunk of complex & unused API, and re-factoring any uses to
simplify our API profile here.
   2nd: simplifying the ImageList - storing BitmapEx's instead of image strips:
this has several benefits:
        + substantially reduces working set - horizontal ImageLists
          are bad news here
        + reduces memory allocation:
             + we demand load images - so far fewer are in-core
             + all BitmapEx's are unique & shared across all top-levels
               (by the impimagetree hash) instead of being duplicated in
               that hash, and also in an ImageList strip [ which tends to
               also be duplicated per window ]. ie. we turn a substantial
               per-window cost (500k?) into a per-app cost.
        + reduces per-user disk cost
             + removes any ~/.ooo-2.0/user/config/imagecache usage - good
               for multi-user systems [ saves ~2.5Mb per user or so ], also
               kills any network latency effects from NFS mounted homes at
               startup relating to this.
             + also using a per-system shared, mmapped 'images.zip' to read
               read these icons, saves a chunk of I/O in shared systems for
               the imagecache - since it'll be warm.
        + reduces code complexity
             + this is a net code size reduction
    3rdly: performance neutral
        + my measurements suggest this makes startup neither substantially
          faster, nor slower - but clearly that will vary depending on
          available memory, processor speed and should give a net win -
          particularly from reduced working set size.
        + also when combined with i#66679# should not generate cold start
          seeking pain.

Potential downsides - changes the VCL API, but doesn't break the ABI - ie. if we
just update the various dependant libraries - all should be well.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to