Open Bug 1811188 Opened 3 years ago Updated 1 year ago

JS demo (https://www.fxhash.xyz/generative/23090) appears to spend ~200ms in GC/CC each time you refresh it

Categories

(Core :: Cycle Collector, defect, P3)

defect

Tracking

()

People

(Reporter: mayankleoboy1, Unassigned)

References

()

Details

Go to https://www.fxhash.xyz/generative/23090
Click on the "Run" button
After the demo renders, you can click on the "Variations" button a couple of times

Nightly: https://share.firefox.dev/3XzhLaQ
Chrome: https://share.firefox.dev/3krP9BY

No idea if this is the expected behaviour or if the demo is written poorly, or if this particular scenario is not worth optimizing for.

It also looks like that total time spent in GC is fairly high while the demo is rendering/running

Seems like the test is using lots and lots ImageData objects and from cycle collector side hold/drop JS objects calls are heavy because of the hashtable usage.
Hashtable operations shows up also on JS side when doing minor GCs.

The testcase is pretty artificial, but I think I've seen holdJsObject calls a bit in speedometer.

Blocks: speedometer3
Severity: -- → S3
Priority: -- → P3

Looks like clicking "Run" triggers creating about 650000 ImageData objects.

But speedometer doesn't trigger these code paths too much, removing dependency after all.

No longer blocks: speedometer3
See Also: → 1813423
Component: XPCOM → Cycle Collector
You need to log in before you can comment on or make changes to this bug.