Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]

[Eli Zaretskii]

> From: "Philip K." <philipk@posteo.net>
> Cc: arthur.miller@live.com, adam@alphapapa.net, rms@gnu.org,
>       emacs-devel@gnu.org
> Date: Tue, 22 Dec 2020 11:38:31 +0100
> 
> >> In that case, gnutls-negotiate seems to be the most suspicious function,
> >> using over 50%-60% of the CPU time, at least on my machine. This also
> >> makes sense, as TLS sites seem to take longer to load than regular,
> >> non-encrypted ones.
> >
> > Please show the code you profiled and the fully expanded profile.
> 
> I sadly coudln't reproduce it, but this time the critical section looked
> something like this:
> 
>         - url-retrieve-synchronously                               212  52%
>          - url-retrieve                                            149  36%
>           - url-retrieve-internal                                  149  36%
>            - url-http                                              136  33%
>             - url-http-find-free-connection                        135  33%
>              - url-open-stream                                     135  33%
>                 open-network-stream                                134  33%
> 
> when evaluating 
> 
>       (url-retrieve-synchronously "http://textboard.org/sexp/prog/index";)
> 
> in the *scratch* buffer. I used emacs -Q (GNU Emacs 27.1 (build 1,
> x86_64-redhat-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0) of
> 2020-08-21), but I don't know why that should make any
> difference. I repeated the same test on the master branch and the
> results were basically the same (±5%).
> 
> Either way, this simple request took over 2.5 minutes, whereas curl
> requires a quarter of a second. Note that this is even unencrypted, so
> this is not even taking the encryption overhead into account.

That's strange, because I get here much faster times: 0.6 sec (with 3
GC cycles) on the first attempt, and less than 0.1 sec afterwards.
How come it's so slow on your system?