[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] GSoC15: Speed up Wget's Download Mechanism

From: Eli Zaretskii
Subject: Re: [Bug-wget] GSoC15: Speed up Wget's Download Mechanism
Date: Fri, 01 May 2015 11:20:52 +0300

> Date: Thu, 30 Apr 2015 19:30:39 +0200
> From: Gisle Vanem <address@hidden>
> CC: address@hidden
> wget -q -O NUL
> "https://download-installer.cdn.mozilla.net/pub/firefox/releases/37.0.2/win32/en-GB/Firefox
>  Setup 37.0.2.exe"
> results in 9931 DLL attach/detaches!
> For a 40 MByte file that is approx. 1 new thread per 4 kByte read.
> I was thinking that increasing read-buffer would help. But where?
> The code is bit of a mess IMHO. Increasing the Rx buffer in
> fd_read_body() didn't help. Is this the chief in this regard?
> Without getting any numbers, I can see in 'Process Explorer'
> that all those run_with_timeout() calls (and no '-T0') amount
> to some more user+kernel time. I guess using a profiler is next.
> Or maybe someone knows of a Win-program that can report total
> CPU (kernel/user) time from the cmd-line?

'timep' from "Windows System Programming" can (let me know if you want
the source I use).  This is based on average of 2 runs of Wget 1.16.1
running on a 32-bit Windows XP, with a 30 Mbit/sec cable connection:

  real    00h01m56.500s
  user    00h00m00.823s
  sys     00h00m00.355s

And here's the same from a GNU/Linux machine that downloads at 20.7

  real    0m2.300s
  user    0m1.600s
  sys     0m0.6000s

> BTW. My ISP gives me 25 Mbit/s in and 10 MBit/s out.

See above; removing -q from the command line indicates that the actual
download speed for this file is around 500 KB/sec.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]