This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

changwan@ perezju@, what perf tests do we have for WebView, aside from startup?

I don't think we can repurpose our startup tests to check support lib in any meaningful way because those tests mainly just call #loadUrl(). Perhaps we could repurpose other tests?

Nearly all perf tests that we run on Chrome, also run on Webview, these include e.g. system health browse stories, plus many others, e.g.:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=performance_webview_test_suite&builder=chromium.perf%3AAndroid%20Nexus6%20WebView%20Perf

cc'ing test engineering FYI

I'd lean towards not worrying about support lib performance.

Start up is mostly going to be loading class and loading the jar.
There are no webview API that happens in a tight loop, so the reflection cost should be negligible.
For these two, there is nothing we can do to improve, and it's unlikely we cause a significant regression in anyway.

I suppose one potential issue is allocating extra java objects each call which has to be gc-ed later. Seems to be like a pretty minor thing though.

On the flip side, there is a lot of maintaining perf tests. So my feeling is the benefit doesn't justify the cost.

I agree with boliu@. I'll close this out unless someone objects.

Is there any way we can create a local patch and run pinpoint to take the pulse?
The biggest worry for me is startup time - is there any chance that art verification failure occurs on support library?

The startup benchmark can't realistically use any lib APIs. The only thing we could do would be to pass a WebViewClientCompat, even though we don't need to use the Compat callbacks.

We could try this locally, and it would give us a partial view of class verification cost. But this would require learning how to pull in AndroidX via GN, and I'm not convinced this is worth the effort.

> is there any chance that art verification failure occurs on support library?

These certainly fail verification. Classes are small, so hopefully not expensive to verify at runtime.

I don't think out-of-lining is reasonable. This would require modifying every class in the support lib. I think we really need an ecosystem-wide fix (as suggested in [1]), which we could then apply to the entire AndroidX repo (not just WebView's module).

[1] https://docs.google.com/document/d/1i5cPpP9tXk6o8FHRO_HyLyvUrVArNo6BCOSoOqk80l8/edit?usp=sharing

Sounds fair. Thanks for the quick answers!