Optimize resource loading from pak files

[Kirill Pleshivtsev]

Hello,

 

WebUI pages download resources via the main process, where they are extracted from the PAK files without any processing and sent via IPC back to the renderer process.

Passing data between processes delays of 1-2 ms per subresourse (can be seen at chrome://net-internals). We can speed up the loading of WebUI pages, if will load resources from a pak file directly from the renderer process.

This requires having a mapping with the name of the resource and its identifier in the PAK file. It requires additional dependencies in the content from ui_resources.gyp:ui_resources and simple handler in web_url_loader_impl.cc.

For example chrome://settings loads the 46 subresources, whose downloading can be optimized.

 

What do you think about this optimization?

 

Regards

drbasic

[Egor Pasko]

chrome://settings does not load on android with chrome, users see the native ui instead. Are there other webui pages that would reveal noticeable speedups from this optimization?

also, as you probably know, renderers are restricted for security reasons, there is a lot of value in keeping security policies as simple as possible.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Michael Giuffrida]

On Mon, Jun 20, 2016 at 1:02 PM Egor Pasko <pa...@chromium.org> wrote:

chrome://settings does not load on android with chrome, users see the native ui instead. Are there other webui pages that would reveal noticeable speedups from this optimization?

who said anything about android? 

also, as you probably know, renderers are restricted for security reasons, there is a lot of value in keeping security policies as simple as possible.

On Jun 20, 2016 10:00, "Kirill Pleshivtsev" <drb...@yandex-team.ru> wrote:

Hello,

 

WebUI pages download resources via the main process, where they are extracted from the PAK files without any processing and sent via IPC back to the renderer process.

Passing data between processes delays of 1-2 ms per subresourse (can be seen at chrome://net-internals). We can speed up the loading of WebUI pages, if will load resources from a pak file directly from the renderer process.

This requires having a mapping with the name of the resource and its identifier in the PAK file. It requires additional dependencies in the content from ui_resources.gyp:ui_resources and simple handler in web_url_loader_impl.cc.

For example chrome://settings loads the 46 subresources, whose downloading can be optimized.

Not sure about the feasibility of this. But we have been looking at ways to reduce IPC when loading WebUI, e.g. https://codereview.chromium.org/1985983002, because new Polymer WebUI like chrome://md-settings loads many more files.

[Kirill Pleshivtsev]

PAK-files are already available from the renderer. It does not require any modifications to the sandbox.

 

 

21.06.2016, 02:42, "Michael Giuffrida" <mich...@chromium.org>:

[Egor Pasko]

I don't think pak files are available to renderers on android, though haven't checked recently. Having two codepaths - not such great.

Do you have a benchmark reflecting some real world usecase? It seems the optimization can potentially save less than 100ms, but webui is not used that often and may be not worth the complexity. Quick experiments would be good to make your case more convincing.

[Elliott Sprehn]

On Tue, Jun 21, 2016 at 12:26 PM, Egor Pasko <pa...@google.com> wrote:

I don't think pak files are available to renderers on android, though haven't checked recently. Having two codepaths - not such great.

Do you have a benchmark reflecting some real world usecase? It seems the optimization can potentially save less than 100ms, but webui is not used that often and may be not worth the complexity. Quick experiments would be good to make your case more convincing.

Note that 100ms absolutely does matter, Web UI needs to be a good example of RAIL. :)

That said, I'd really rather we didn't add hacks specific to Web UI. If resource loading is "too slow" we need to fix it for all web pages. The less special Web UI is the better.

- E

[Kirill Pleshivtsev]

Thnx!

21.06.2016, 17:04, "Elliott Sprehn" <esp...@chromium.org>:

[Dan Beam]

On Mon, Jun 20, 2016 at 1:00 AM, Kirill Pleshivtsev <drb...@yandex-team.ru> wrote:

Hello,

 

WebUI pages download resources via the main process, where they are extracted from the PAK files without any processing and sent via IPC back to the renderer process.

The "without any processing" becomes less true every day :).  For a subset of chrome:// page resources, we use the syntax (for example):

  <h1>$i18n{title}</h1>

which gets replaced/expanded in the browser process to:

  <h1>Page title</h1>

before being sent to the renderer to reduce flicker. More context here: https://crbug.com/506009

It's probably quite feasible / better to do this in the renderer instead, though.  We've always known that doing templating like this in the browser process on the UI thread would need to change if it were ever to take noticeable time.

Note: strings can be created dynamically (i.e. change "Open # things" to "Open 3 things", etc.), and often the information needed to do this is deals with profile-specific or global services that are likely easier to access from the browser process.

Passing data between processes delays of 1-2 ms per subresourse (can be seen at chrome://net-internals). We can speed up the loading of WebUI pages, if will load resources from a pak file directly from the renderer process.

This requires having a mapping with the name of the resource and its identifier in the PAK file.

It requires additional dependencies in the content from ui_resources.gyp:ui_resources and simple handler in web_url_loader_impl.cc.

Right, currently the URL navigated to creates a WebUI controller.  This controller creates a data source and registers resources to that data source.  That's how chrome://settings/some/sub/file.js works.

However, sometimes we vary the content based on a switch or experiment, i.e.:

data_source->SetDefaultResource(

    IsFancyNewVersion() ? IDR_FANCY_NEW_HOME_PAGE : IDR_OLD_HOME_PAGE);

We'd just need to make sure the data used to vary these responses (i.e. switches, experiments) are mirrored correctly to the renderer.

For example chrome://settings loads the 46 subresources, whose downloading can be optimized.

 

What do you think about this optimization?

I think it's worth looking into, for sure, as long as we can maintain the existing behavior/requirements (i.e. dynamically serving resources, doing $i18n{} replacements).  Maybe just start by figuring out how to serve totally static resources from the renderer and otherwise fallback to browser + IPC?

-- Dan

[Dan Beam]

On Tue, Jun 21, 2016 at 4:03 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Jun 21, 2016 at 12:26 PM, Egor Pasko <pa...@google.com> wrote:

I don't think pak files are available to renderers on android, though haven't checked recently. Having two codepaths - not such great.

Do you have a benchmark reflecting some real world usecase? It seems the optimization can potentially save less than 100ms, but webui is not used that often and may be not worth the complexity. Quick experiments would be good to make your case more convincing.

Where are you getting this number from?  Absolute numbers in the performance realm isn't too helpful, as it's unclear to me whether you mean 100ms on your beefy Linux desktop or a slow, old machine.  FWIW: I've seen the whole downloads page load for me in 150ms for me on a fancy Macbook pro.

Note that 100ms absolutely does matter, Web UI needs to be a good example of RAIL. :)

That said, I'd really rather we didn't add hacks specific to Web UI. If resource loading is "too slow" we need to fix it for all web pages. The less special Web UI is the better.

I think this would be partially undoing "WebUI specialness".  How does a file:/// URL respond with a resource?  From the renderer or browser+IPC?  Where do local web page caches live (i.e. if a response 304s, where do we load it from)?

-- Dan

 

- E

[Elliott Sprehn]

Did a bug ever get filed here to optimize the pak file resource loading pipeline?