Because slowness in itself isn't a bug. Whatever's causing the slowness may be, but that may or may not be WordPress' fault (for example, an improper server configuration has been known to cause this as well). That's why I suggested the forums. Once it's determined (via the support forums) what's causing the slowness and if it is WordPress at fault, then by all means a ticket is in order. For now though, there's nothing to go on.

tin68: Are you getting plugin update notices at all? I'm just wondering if it could be related to external HTTP requests. It will be a conflict between WordPress and your hosting environment, It could be a bug in WordPress, or it could be a oddity in the way your host has PHP set up, Its a bit hard to tell which without testing.

tin68: I assume that was after you disabled the requests? How long was it taking before?

By disabling the HTTP requests you loose Cron(which means no pinging of sites, and various other items), Plugin updates/install/core updates/upgrade, etc, so theres a few things that hang off it.

Ryan posted up a plugin at some stage which listed the transports in use for the HTTP API, If someone see's this comment, can they post a link up to it? I cant find it right now (And dont feel like re-inventing the wheel)

Before your suggested change to http.php the loading time was 5 to 7 seconds.

What are the requirements for the server that the default http.php runs without this big delay? BTW I installed an other WP 2.7 (without any plugins and default theme) on an other server without these delay.

Well, Seems curl could be unusable on your host, Not sure why, realistically, if Curl failed, you'd expect the others to fail too. But that just isnt the case. Perhaps you could contact your host and ask if Curl is enabled, Mention that once you changed WordPress from using Curl, to using fopen() the performance issues went away.

The only way to resolve this ticket will be to workout why curl doesnt work on your host, But i'm not expecting [the host] to give a reason for it not working, You might be one of the people who needs to install a plugin to disable the Curl transport in order for WP to work as intended.

I opened #8622 to deal with fallover to other transports if one fails, and that would fix the non-working requests for you, but could also increase the delays on loading.

same problem here, inserting the return in http.php works for me.
Server Info:
Current WordPress version 2.7
Server operating system Linux
Current version of PHP PHP 5.2.0-8+etch13
Current version of MySQL MySQL 5.0.32-Debian_7etch8-log
Webserver software Apache/2.2.3 (Debian) DAV/2 PHP/5.2.0-8+etch13 mod_ssl/2.2.3 OpenSSL/0.9.8c

I asked the provider if he could update this very old version - the only answer I got: This version is a patched version to handle a lot of file descriptors... I don't know but perhaps the curl problems we have are coming from this patch...?

Well, I am quite disappointed about my provider - seems that he is not very interested to help...

when the response fails, WP should store a valid response that signals no updates, including the version_checked, and try again later. as things currently are, it tries again on every page load because of _maybe_update_core().