Bugzilla

Thank you for the profiles!  I agree they don't show a smoking gun, but for my purposes they do at least seem to show that there's no meaningful impact of mozStorage on the main thread of the parent process, or of IndexedDB/friends.  That said, the Network tables for the profiles do seem to be showing somewhat different network panel timings, including some bi-modal values and intensely different "Waiting to transmit the response" AKA responseEnd phases in the content processes.  I wonder if the network proxy thing itself could be experiencing disk I/O contention from Places activity or something like that.

Your general theory in comment 10 that small changes in behavior can result in emergent changes in behavior seems quite reasonable to me; for example the 163.com cycle_0 bad profile seems to show an HTML tree flush bisecting two very large reflows whereas the good profile seems to have only a single continuous reflow.  This could make sense if the network behavior has been impacted by

I think this leaves things to be just a places problem domain issue so I'll leave it to :mak's expertise.

Thank you for the profiles!  I agree they don't show a smoking gun, but for my purposes they do at least seem to show that there's no meaningful impact of mozStorage on the main thread of the parent process, or of IndexedDB/friends.  That said, the Network tables for the profiles do seem to be showing somewhat different network panel timings, including some bi-modal values and intensely different "Waiting to transmit the response" AKA responseEnd phases in the content processes.  I wonder if the network proxy thing itself could be experiencing disk I/O contention from Places activity or something like that.

Your general theory in comment 10 that small changes in behavior can result in larger emergent changes in behavior seems quite reasonable to me; for example the 163.com cycle_0 bad profile seems to show an HTML tree flush bisecting two very large reflows whereas the good profile seems to have only a single continuous reflow.  Unfortunately, it seems like it's a bigger undertaking to sample across many different profiler runs.

I think this leaves things to be just a places problem domain issue so I'll leave it to :mak's expertise.

Thank you for the profiles!  I agree they don't show a smoking gun, but for my purposes they do at least seem to show that there's no meaningful impact of mozStorage on the main thread of the parent process, or of IndexedDB/friends.  That said, the Network tables for the profiles do seem to be showing somewhat different network panel timings, including some bi-modal values and intensely different "Waiting to transmit the response" AKA responseEnd phases in the content processes (likely due to the reflow jank).  I wonder if the network proxy thing itself could be experiencing disk I/O contention from Places activity or something like that.

Your general theory in comment 10 that small changes in behavior can result in larger emergent changes in behavior seems quite reasonable to me; for example the 163.com cycle_0 bad profile seems to show an HTML tree flush bisecting two very large reflows whereas the good profile seems to have only a single continuous reflow.  Unfortunately, it seems like it's a bigger undertaking to sample across many different profiler runs.

I think this leaves things to be just a places problem domain issue so I'll leave it to :mak's expertise.