What you are looking for sounds pretty much like my Backtrack project
[1]. It's still under development, tho, but I have strong motivations
to move it forward in Q4/17. The goal of Backtrack is exactly what you
are looking for - find the right scheduling prioritization. It's said
we don't hav
On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione wrote:
> One of my biggest frustrations in profiling startup performance has been
> the fact that exactly which code runs during before or after first paint
> changes based on arbitrary timing factors. If I make a 5ms improvement to
> one section of c
During FxOS days we spent a lot of time designing the "bootstrapping" stages of
the app/system.
We came up with 5 stages:
1) navigationLoaded
2) navigationInteractive
3) visuallyLoaded
4) contentInteractive
5) fullyLoaded
https://hacks.mozilla.org/2015/06/performance-testing-firefox-os-with-rap
On Tue, Aug 08, 2017 at 06:09:05PM -0700, Robert Strong wrote:
One thing that comes to mind is how some code registers app specific
observers so the code runs after the UI is displayed.
...
Perhaps having a single category for after UI has been displayed that
components can specify in their mani
One thing that comes to mind is how some code registers app specific
observers so the code runs after the UI is displayed.
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#180
https://dxr.mozilla.org/mozilla-central/source/devtools/shared/system.js#24
https:/
One of my biggest frustrations in profiling startup performance
has been the fact that exactly which code runs during before or
after first paint changes based on arbitrary timing factors. If
I make a 5ms improvement to one section of code, a 100ms chunk
of code winds up running after first pai
6 matches
Mail list logo
