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

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Yeong-woo Cho]

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.

Comment 1

[Yeong-woo Cho]

Additionally, two same copies of an encoded image are maintained each in the image cache and mRestoredData.

Comment 2

[Ria Klaassen (not reading all bugmail)]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is the perf impact noticeable in profiles?

Comment 4

[Yeong-woo Cho]

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.

Comment 5

[Alfred Kayser]

Marking WONTFIX as the impact is negligible.