Using these steps: - enable profiler - click the link in comment 14 - click in the table on the first page - type for 20 seconds or so - capture profile - in perf.html, click on the "Web Content" process (only one has significant activity during the profile). On my machine, we're idle 32% of the time; and 27% of total time is spent under js::jit::IonGetPropertyIC::update (doing actual property lookups), and more than half of that (18% of the total) is on a single stack. This made me wonder if it might be actionable as a JS JIT bug, but: ``` <djvj> jorendorff: P3. Not pageload, and it only shows up on huge docs. Also, doing further perf improvements on it probably requires a rethink of how we structure objects and sparse arrays. ``` Leaving P1 for now because it's hard to buy that this is really P3, even if the JS engine side of things is too hard to tackle. There's still the 32% idle time.
Bug 1488435 Comment 20 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Using these steps: - enable profiler - click the link in comment 14 - click in the table on the first page - type for 20 seconds or so - capture profile - in perf.html, click on the "Web Content" process (only one has significant activity during the profile). On my machine, we're idle 32% of the time; and 27% of total time is spent under js::jit::IonGetPropertyIC::update (doing actual property lookups), and more than half of that (18% of the total) is on a single stack. This made me wonder if it might be actionable as a JS JIT bug, but: ``` <djvj> jorendorff: P3. Not pageload, and it only shows up on huge docs. Also, doing further perf improvements on it probably requires a rethink of how we structure objects and sparse arrays. ``` Leaving P1 for now because it's hard to buy that this is really P3, even if the JS engine side of things is too hard to tackle. There's still the 32% idle time.
Using these steps: - enable profiler - click the link in comment 14 - click in the table on the first page - type for 20 seconds or so - capture profile - in perf.html, click on the "Web Content" process (only one has significant activity during the profile). On my machine, we're idle 32% of the time; and 27% of total time is spent under js::jit::IonGetPropertyIC::update (doing actual property lookups), and more than half of that (18% of the total) is on a single stack. This made me wonder if it might be actionable as a JS JIT bug, but: > \<djvj\> jorendorff: P3. Not pageload, and it only shows up on huge docs. Also, doing further perf improvements on it probably requires a rethink of how we structure objects and sparse arrays. Leaving P1 for now because it's hard to buy that this is really P3, even if the JS engine side of things is too hard to tackle. There's still the 32% idle time.
Using these steps: - enable profiler - click the link in comment 14 - click in the table on the first page - type for 20 seconds or so - capture profile - in perf.html, click on the "Web Content" process (only one has significant activity during the profile). On my machine, we're idle 32% of the time; and 27% of total time is spent under js::jit::IonGetPropertyIC::update (doing actual property lookups), and more than half of that (18% of the total) is on a single stack. This made me wonder if it might be actionable as a JS JIT bug, but: > <djvj\> jorendorff: P3. Not pageload, and it only shows up on huge docs. Also, doing further perf improvements on it probably requires a rethink of how we structure objects and sparse arrays. Leaving P1 for now because it's hard to buy that this is really P3, even if the JS engine side of things is too hard to tackle. There's still the 32% idle time.