GNOME Bugzilla – Bug 606087
[PATCH] Make soup prepare for URLs (prefetch DNS, proxy, etc) which are suggested by autocompletion
Last modified: 2011-02-24 18:44:09 UTC
This patch calls soup_session_prepare_for_uri when a URI is suggested by location bar autocompletion. soup_session_prepare_for_uri does currently only do DNS prefetching, but may in the future handle proxies also (see #605065)
Created attachment 150826 [details] [review] Patch for calling prepare_for_uri when a URI is suggested by location bar autocompletion
José, this can be a LOT of hits. Say you type 'e' very slowly or other popular letter. Ugh. I'd like to see bug #547899 before this. I like the idea though, but maybe something could be done to limit it to the ten topmost results after a typying pause by the user. Do consequent calls to soup_session_prepare_for_uri () hit the dns again or do nothing given that they already cached the info?
(In reply to comment #2) > Do consequent calls to soup_session_prepare_for_uri () hit the dns again or do > nothing given that they already cached the info? If the first one succeeded, the second one will be a no-op. If the first one failed, it will try again if you call soup_session_prepare_for_uri() again. (SoupAddress behaves that way so that like if you can only resolve some hostnames when you're on a VPN, we don't cache the failure to resolve them when you're off the VPN.)
Created attachment 181478 [details] [review] Patch Another approach, just prefetch the autocompletion entry the cursor is over. Some numbers BTW using Google's web-page-replay with these settings: upload: 64Kbit download: 2 Mbit packet loss rate: 1% delay: 50msecs | bbc.co.uk | 260 | 130 | | cnn.com | 235 | 115 | | google.com | 265 | 130 | | igalia.com | 190 | 130 | | csszengarden | 220 | 120 |
(In reply to comment #4) > | bbc.co.uk | 260 | 130 | > | cnn.com | 235 | 115 | > | google.com | 265 | 130 | > | igalia.com | 190 | 130 | > | csszengarden | 220 | 120 | Those numbers are msecs until the first load starts.
Review of attachment 181478 [details] [review]: ::: lib/widgets/ephy-location-entry.c @@ +1056,3 @@ + + if (entry->priv->dns_prefetch_handler) + g_source_remove (entry->priv->dns_prefetch_handler); If there's already a prefetch scheduled for this URL shouldn't we just exit? @@ +1090,3 @@ le->priv->block_update = FALSE; + schedule_dns_prefetch (le, 250, (const gchar*) url); no space between the cast and url?
(In reply to comment #6) > Review of attachment 181478 [details] [review]: > > ::: lib/widgets/ephy-location-entry.c > @@ +1056,3 @@ > + > + if (entry->priv->dns_prefetch_handler) > + g_source_remove (entry->priv->dns_prefetch_handler); > > If there's already a prefetch scheduled for this URL shouldn't we just exit? Actually the old prefetch target could be any URL, we'd need a hash to keep track of every prefetch request. As this patch just request a prefetch when the cursor is over an autocompleted entry we might think that the user is just interested in the last one and not in any previous ones. We could easily add some more prefetching points in any other parts of the code (that's why schedule_dns_request was created) but I started just for one of the easy ones. We could think about issuing a prefetch also some time after the last user edition in the location bar for example. > @@ +1090,3 @@ > le->priv->block_update = FALSE; > > + schedule_dns_prefetch (le, 250, (const gchar*) url); > > no space between the cast and url? ok
(In reply to comment #7) > > If there's already a prefetch scheduled for this URL shouldn't we just exit? > > Actually the old prefetch target could be any URL, we'd need a hash to keep > track of every prefetch request. As this patch just request a prefetch when the > cursor is over an autocompleted entry we might think that the user is just > interested in the last one and not in any previous ones. > > We could easily add some more prefetching points in any other parts of the code > (that's why schedule_dns_request was created) but I started just for one of the > easy ones. We could think about issuing a prefetch also some time after the > last user edition in the location bar for example. > Right, I was thinking of storing the URL and id and check if they are the same, that would be an easy intermediate step that does not require a full hash table; but I guess it's not very important. Since this seems to be a big improvement anyway I think we can go for it.
Committed 7b24139e069c3de30cdafe983cfb6eb90c097362