Measure deflated string cache

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: gal, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
The deflated string cache has a serious finalization cost in the GC. We should measure what benefits we get out of it at runtime in practice.
(Reporter)

Comment 1

9 years ago
Proposed measurement approach:

- Measure hit ratio and total browser memory use with the current code.

- Disable the cache (i.e. make it always miss) and then measure total browser memory use again.

We should also measure how often we hit js_DeflateString in general, and how much time we spend inside of it.
(In reply to comment #1)
> Proposed measurement approach:
> 
> - Measure hit ratio and total browser memory use with the current code.
> 
> - Disable the cache (i.e. make it always miss) and then measure total browser
> memory use again.

Do you know what you're proposing here? "Disable the cache" must leak returned string byte vectors, since there is no mandatory JS_PutStringBytes API. So you will measure the leaks accumulating, not merely the loss of sharing due to the disabled cache.

> We should also measure how often we hit js_DeflateString in general, and how
> much time we spend inside of it.

It would be great to measure lifetime of strings from which deflated bytes are accessed.

Note that we already use a DEFLATED flag bit in the JSString header to avoid the costly finalization. Are you sure you're not on a snipe hunt?

Also note bug 491579 especially bug 491579 comment 10.

/be

Comment 3

6 years ago
This has all been removed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.