997007 - [Tarako] What of freetype is allocating memory

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Performance, defect, P2)

Description

[Ting-Yu Chou [:ting] (away)]

While working on Tarako bug 989713, about memory (attachment 8406762 [details]) shows freetype consumes ~6MB memory at inbox page of Email, I'd like to figure out what of freetype is allocating memory, and see if there're chances to lower it.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Is this just a consequence of using a font different from our typical Fira Sans?

Comment 2

[Ting-Yu Chou [:ting] (away)]

Seems so, there're emails with Chinese subject from the test account, I will still take a look to confirm.

BTW, I checked also Messages app which has only English titles, freetype takes just ~0.3 MB.

Comment 3

[Ting-Yu Chou [:ting] (away)]

Without Chinese subject emails, freetype takes ~0.2 MB.

Comment 4

[Ting-Yu Chou [:ting] (away)]

Attachment: dmd of email when there're chinese subjects

Disabled FreetypeReporter, and got DMD report for the stack allocating memory when there're Chinese subject emails.

Comment 5

[Ting-Yu Chou [:ting] (away)]

I put 4 Chinese characters on one email subject, and checked FreetypeReporter's difference between gfxFontGroup::FindFontForChar() invocaitons:

  D/TINGf   (  510): #0 217652 font=Fira Sans OT Medium
  D/TINGf   (  510): #6 3093824 font=MotoyaLMaru W3 mono
  D/TINGf   (  510): #6 3093824 font=MotoyaLMaru W3 mono
  D/TINGf   (  510): #6 3093824 font=MotoyaLMaru W3 mono
  D/TINGf   (  510): #6 3093824 font=MotoyaLMaru W3 mono
  D/TINGf   (  510): #0 3097040 font=Fira Sans OT

Traced freetype2 a bit, it allocates a buffer for storing uncompressed SFNT from the MotoyaLMaru woff.

Comment 6

[Ting-Yu Chou [:ting] (away)]

Aside from woff things, freetype2 does support memory-mapped files:

http://www.freetype.org/freetype2/docs/design/design-4.html

<quote>
  However, the Unix build of FreeType 2 provides an alternative implementation that uses memory-mapped files, when available on the host platform, resulting in a significant access speed-up.

  FreeType distinguishes between memory-based and disk-based streams. In the first case, all data is directly accessed in memory (e.g. ROM-based, write-only static data and memory-mapped files), while in the second, portions of the font files are read in chunks called frames, and temporarily buffered similarly through typical seek/read operations.
</quote>

I will check is this used.

Comment 7

[Thinker Li [:sinker]]

After looking into the code of freetype, it dues to uncompressed font data of WOFF.  All compressed data of WOFF is uncompressed into a block of memory during open.  I suggest to use other format to avoid this block of memory (~2.7MB).

Comment 8

[Ting-Yu Chou [:ting] (away)]

memory-mapped FT_Stream_Open() is not enabled on Tarako:

  objdir-gecko/modules/freetype2/config.log:
    configure:4344: checking for working mmap
    configure:4501: result: no

  objdir-gecko/modules/freetype2/unix-def.mk:
    FTSYS_SRC = $(BASE_DIR)/ftsystem.c

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Thinker Li [:sinker] from comment #7)
> After looking into the code of freetype, it dues to uncompressed font data
> of WOFF.  All compressed data of WOFF is uncompressed into a block of memory
> during open.  I suggest to use other format to avoid this block of memory
> (~2.7MB).

The alternative is to use (uncompressed) .ttf files, but this will significantly increase the size of the ROM image, which was apparently a problem for Tarako. Somehow we'll have to decide whether ROM size or RAM usage is the more critical issue here, as we can't optimize for both at the same time.

Comment 10

[Thinker Li [:sinker]]

Thomas, How do you think?

Comment 11

[thomas tsai]

In order to save the rom size, we will verify again if all indian related .ttf fonts can be included.

Comment 12

[Kai-Zhen Li [:seinlin][:kli]]

In case of we need to use ttf fonts becasue of performance regression, I think we should remove those fallback fonts with larger size but it would be better to include some Indian related fonts.

Comment 13

[Andreas Gal :gal]

Is the font unloaded when a memory pressure event occurs? (and then re-loaded) If so this could be ok.

Comment 14

[Ting-Yu Chou [:ting] (away)]

The memory-pressure observer gfxFontCache::Observer::Observe() clears only shapped-word caches. Please also note uncompressing WOFF font takes time, see bug 992150, comment 54.

Comment 15

[Ting-Yu Chou [:ting] (away)]

Options for storing uncomprssed WOFF:

  File based:
    a. SD card
    b. data partition
  Memory based:
    c. share between processes by ashmem

Had some discussions with Kai-Zhen Li:

  a) Not ok since maybe there won't be a SD card
  b) There're only ~80MB space on data partition, and all the uncompressed fonts are ~20MB
  c) Still need memory for storing uncompressed fonts

Any other ideas?

# Note from bug 992150, removing fonts seems not a good idea.

Comment 16

[Kai-Zhen Li [:seinlin][:kli]]

I agree removing fonts could not be a good idea. But Tarako is a special project and that's why it got its own branch v1.3t, so I think having some tradeoff is fair to it. The tradeoff is do not use compressed fonts and remove a few fonts which could make tarako not working properly.

Comment 17

[Ting-Yu Chou [:ting] (away)]

Closed as the source of allocating memory has been spotted, and there's no more actions needed from this topic.