Memory reporter for in-memory blobs probably shouldn't SHA-1 hash memory contents

NEW
Unassigned

Status

()

Core
DOM
3 years ago
3 years ago

People

(Reporter: erahm, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

In bug 803684 a memory reporter was added to nsDomMemoryFile. A SHA-1 hash is calculated for the entire contents of the memory to uniquely identify the file [1]. This seems excessive on B2G, particularly for large files. 

I'd suggest just removing that portion of the name or possibly using the memory address instead.

Current example:
>├───2.05 MB (03.14%) -- dom
>│   ├──2.05 MB (03.14%) -- memory-file-data
>│   │  ├──2.04 MB (03.12%) -- large
>│   │  │  ├──2.00 MB (03.06%) ── file(length=2021265, sha1=f74a363c92eea93ee5000eb7bfc51a159e627a75)
>│   │  │  └──0.04 MB (00.06%) -- (2 tiny)
>│   │  │     ├──0.03 MB (00.05%) ── file(length=29298, sha1=1fd8d4dedaf47f344f0ef5830fa3dddddeb17211)
>│   │  │     └──0.01 MB (00.01%) ── file(length=5420, sha1=6538f4acd0f5e55289ceee30f045f8d0dc59c1bd)

Proposed:
>│   │  │  ├──2.00 MB (03.06%) ── file(length=2021265, address=0x12345678)
or
>│   │  │  ├──2.00 MB (03.06%) ── file(length=2021265)


[1] https://hg.mozilla.org/mozilla-central/annotate/09f4968d5f42/dom/base/File.cpp#l1135
Hmm, yes. Worth fixing. How did you find this -- profiling, code inspection, something else?

But I don't think it needs a MemShrink tag, because it won't reduce memory consumption or affect memory reporting coverage.
Whiteboard: [MemShrink]
The reason we do this is so that we can find blobs that are "duplicated" in memory.
You need to log in before you can comment on or make changes to this bug.