As measured in bug 1160228 comment 4 incremental GC impacts startup performance, especially in sessions with many tabs. Since latency does not matter much until the first tab to be restored becomes interactive there is not much benefit from 10ms (default) incremental GC slices. Disabling incremental GC completely or increasing the slice time (bug 1160228 comment 7) to something like 100ms until the first tab reaches interactive state could thus reduce startup time. A more general solution might be dynamically adjusting the incremental slice time based on throughput. I.e. estimate time spent in GC vs. time spent in application code and increase the slice time if too much is spent on GCs.

According to bug 1160228 comment 9, the incremental throughput issues should be largely solved by bug 1214961, which should be landing today or tomorrow. We'll of course wait for you to test, but I expect the next step will be to figure out why gecko thinks it needs to request a compacting GC in the middle of startup.

there seems to be a significant improvement compared to bug 1160228 comment 1 Testing with 1000 background tabs in a separate panorama group, e10s off, no addons. incremental off: 39s, 38s, 39s incremental on, 10ms slice: 50s, 49s, 48s So incremental still affects throughput, but now it's only by a fraction instead of a factor > 1.

a few more data points, this time from my real profile with addons and more tabs: -e10s, +incremental: 8m02 -e10s, -incremental: 6m30 +e10s, +incremental: 1m34 +e10s, -incremental: 1m32 Not sure what to make of it. I guess it's some combined effect of the system zone getting smaller for each process (thus reducing individual GC pauses) and one process being able to GC while the other does work? Anyway, it's good news since - at least as far as startup is concerned - e10s masks any impact incremental might have and also reduces time by more than a factor of two. Good enough for me, marking as resolved.