Status Update
No update yet.
Comments
ab...@google.com
We would need more information to investigate this further.
- Could you try if this is reproducible in chrome?
- Could you please provide a simple test app where this can be reproduced?
ab...@google.com
bu...@google.com
Some errors occurred during initial polling, but I will retry for a bit longer before I give up as they might be transient.
I should wait for
* uninitializedObstacle: obstacles are not initialized yet: [bugs.BugUpdate]
pa...@gmail.com
bh...@gmail.com
pa...@gmail.com
bu...@google.com
as...@google.com
I've done a bit of bisecting and can notice that there appears to be a difference in performance between 99.0.4767.0 and 99.0.4768.0. That's still quite a large range of commits, though. I've not been able to bisect further.
Versions 99.0.4767.0 or prior usually have a stall time of around 30-40ms for each of the main.dart.js_2.part.js and main.dart.js_160.part.js resources on my particular emulator setup. Versions 99.0.4768.0 and later seem to have roughly double the stall time of around 60-80ms. I've seen variability in the stall time on both sides of the bisect, but there does at least tend to be good reproducibility.
One thing I observed is that the large delay isn't seen when the intercept is made with a standalone request. For example, navigating to the main.dart.js_160.part.js file directly only costs around 10ms on recent versions. The first main.dart.js script loaded in the document also doesn't have that large of a stall time, despite being served through an interception.
@reporter, is it possible for you to share the source code for the test app you submitted?
mi...@google.com
bugjuggler: ((
mi...@google.com
I were trying to reverting some suspect Cls locally, but 99.0.4768.0 wasn't built because of the system library dependency issue.
I didn't run per-cl bisect.
@Next Bugcop, might run per-cl bisect or wait for the reporter's source code.
nt...@google.com
Friendly ping. Reporter, can you please share source code for the test app?
pa...@gmail.com
nt...@google.com
Hi reporter. I tried using your sample app today but I don't see anything which is obviously slow to load (visible from the user experience). What should I be looking for? Your bug report says shouldInterceptRequest is taking 200ms, but that's still a bit too quick for me to easily see the slow down. Would it be possible to revise your sample app to load a large HTML file via shouldInterceptRequest?
I have a strong suspicion this is a duplicate of
nt...@google.com
If you can reproduce this on your end, you could also try using WebView DevTools (instructions:
nt...@google.com
Please see
I still haven't 100% confirmed this is a duplicate of that bug, however this description sounds like this is very similar.
ja...@google.com
I tried installing your app and clicking "CLICK ME". With OptimizeNetworkBuffers disabled, I see main.dart.js_2.part.js taking 4.6ms to complete loading on a Pixel 2. With OptimizeNetworkBuffers enabled (stable version, without my latest fix above) it takes 3.8ms. Bigger files like main.dart.js took 526ms before and 112ms after.
@ntfschr: I didn't see available() returning 1 in this app through clicking around.
nt...@google.com
Ack. Thanks for taking a look, sounds like it's unlikely to be OptimizeNetworkBuffers. Let's see if the reporter can provide a better repro app with obvious slowdown, otherwise there's not much we can do until then.
pa...@gmail.com
In my case, main.dart.js_2.part.js is taking more than 200ms, irrespective of devices. I have tested on, Higher end and lower end devices. Earlier, even larger main.dart.js files used to take around 10-20ms, I had doubt about file reading from disk might be a culprit so I loaded them in memory as soon as application initialised, but still the result is same.
Larger data sample app is not possible, we have seen same behaviour in our production app.
pa...@gmail.com
106.0.5249.79
106.0.5249.126
nt...@google.com
Why is it not possible to have a more significant slowdown? What happens if you change the resources to be on the order of megabytes larger in size?
Unfortunately 200 ms just isn't enough of a slowdown for the human eye to notice. I recognize this is still impactful for your app, but we really need a way to quickly distinguish between the regression and the good behavior.
ok...@google.com
WebView bugcop:
pandey.adarsh147@, could you please address
Thanks!
av...@google.com
I am not sure if we can make a better configurable to make this more reproducible. And it doesn't seem like we have enough info to diagnose if this is a WebView regression. I am closing this for now and we can come back to this if the reporter provides more information or a more reproducible configuration.
Description
Loading resources using shouldInterceptRequest in WebView taking more than 200ms even for 10 bytes data.
check main.dart.js_2_part.js file it is just 4Byte file. This is taking huge time.