After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 606087 - [PATCH] Make soup prepare for URLs (prefetch DNS, proxy, etc) which are suggested by autocompletion
[PATCH] Make soup prepare for URLs (prefetch DNS, proxy, etc) which are sugge...
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: [obsolete] URL bar
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-01-05 09:41 UTC by José Millán Soto
Modified: 2011-02-24 18:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for calling prepare_for_uri when a URI is suggested by location bar autocompletion (660 bytes, patch)
2010-01-05 09:42 UTC, José Millán Soto
none Details | Review
Patch (3.06 KB, patch)
2011-02-21 17:48 UTC, Sergio Villar
reviewed Details | Review

Description José Millán Soto 2010-01-05 09:41:35 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)
Comment 1 José Millán Soto 2010-01-05 09:42:30 UTC
Created attachment 150826 [details] [review]
Patch for calling prepare_for_uri when a URI is suggested by location bar autocompletion
Comment 2 Diego Escalante Urrelo (not reading bugmail) 2010-01-14 04:58:17 UTC
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?
Comment 3 Dan Winship 2010-01-14 13:12:19 UTC
(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.)
Comment 4 Sergio Villar 2011-02-21 17:48:11 UTC
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 |
Comment 5 Sergio Villar 2011-02-21 17:53:10 UTC
(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.
Comment 6 Xan Lopez 2011-02-21 18:29:44 UTC
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?
Comment 7 Sergio Villar 2011-02-21 19:04:53 UTC
(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
Comment 8 Xan Lopez 2011-02-21 19:13:03 UTC
(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.
Comment 9 Sergio Villar 2011-02-24 18:44:09 UTC
Committed 7b24139e069c3de30cdafe983cfb6eb90c097362