Closed Bug 997007 Opened 5 years ago Closed 5 years ago
[Tarako] What of freetype is allocating memory
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.
Summary: What of freetype is allocating memory → [Email] What of freetype is allocating memory
Is this just a consequence of using a font different from our typical Fira Sans?
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.
Without Chinese subject emails, freetype takes ~0.2 MB.
Disabled FreetypeReporter, and got DMD report for the stack allocating memory when there're Chinese subject emails.
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.
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.
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).
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
(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.
Thomas, How do you think?
In order to save the rom size, we will verify again if all indian related .ttf fonts can be included.
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.
Is the font unloaded when a memory pressure event occurs? (and then re-loaded) If so this could be ok.
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.
Summary: [Email] What of freetype is allocating memory → [Tarako] What of freetype is allocating memory
Whiteboard: [MemShrink], [c=memory p= s= u=] → [MemShrink:P2], [c=memory p= s= u=]
Priority: -- → P2
Whiteboard: [MemShrink:P2], [c=memory p= s= u=] → [MemShrink:P2], [c=memory p= s= u=tarako]
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.
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.
Closed as the source of allocating memory has been spotted, and there's no more actions needed from this topic.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Component: General → Performance
Whiteboard: [MemShrink:P2], [c=memory p= s= u=tarako] → [c=memory p= s=2014.08.01.t u=tarako] [MemShrink:P2]
You need to log in before you can comment on or make changes to this bug.