Inefficient storing operation for encoded image data to support discarding decoded image.

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
11 years ago
8 years ago

People

(Reporter: icho909, Unassigned)

Tracking

({perf})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2008081914 Minefield/3.0b2

To fix bug 296818, mRestoreData is added in the imgContainer class.
It seems to be used to back up imcoming encoded image data for the purpose of restoring discarded decoded image in tens of seconds. So whenever a segment of image file comes from network, it is copied to mRestoreData. But the copy operation seems a lot inefficient because the type of mRestoreData is nsTArray<char>.

mRestoreData.AppendElements(aBuffer, aCount) is invoked to append incoming segment and it's like below :

  template<class Item>
  elem_type *AppendElements(const Item* array, size_type arrayLen) {
      if (!EnsureCapacity(Length() + arrayLen, sizeof(elem_type)))
        return nsnull;
      index_type len = Length();
      AssignRange(len, arrayLen, array);
      IncrementLength(arrayLen);
      return Elements() + len;
    }

   (1) nsTArray<T>::EnsureCapacity() reallocate continuous memory but a linked list of imcoming segments seems better approach.
   (2) nsTArray<T>::AssignRange() calls constructor for every "char" element in the segment but one memcpy() seems enough. The dtor are also called many times while iterating all the array members.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Additionally, two same copies of an encoded image are maintained each in the image cache and mRestoredData.
Summary: Inefficient restoring operation for encoded image data to support discarding decoded image. → Inefficient storing operation for encoded image data to support discarding decoded image.
Assuming it's correct what you are telling I will make this bug blocking bug 296818 so some people are notified and it won't be overlooked.
Blocks: 296818
Component: General → ImageLib
Product: Firefox → Core
QA Contact: general → imagelib
Version: unspecified → Trunk
Is the perf impact noticeable in profiles?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Contrary to my expectation, the performance impact is negligible when compiled with -O2 option in i686 linux. It seems that gcc compiler optimizes well enough for this situation.
Marking WONTFIX as the impact is negligible.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.