[Webkit-unassigned] [Bug 68160] curl backend has horrible performance

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=68160





--- Comment #14 from Onne Gorter <o.gorter at activevideo.com>  2012-08-06 02:27:49 PST ---
> ... Anyhow this issue can be avoided by keeping trac of time spend on emptying buffer.

I think you misunderstand the issue. When a file becomes readable, your select (or epoll/kqueue) will wake up. Then you actually read. You should read until the kernel buffer is empty (not until the remote is done sending!). So put the fd into nonblocking, and read until EWOULDBLOCK.

A slow server means you read a few bytes, and then go back to the mainloop. Much later the kernel receives the next few bytes, and wakes your select again, you read some more... no issue there.

However, a fast server, means you read from the kernel using a 16k buffer, but the kernel has maybe a half a meg worth of data ready. The current implementation will read 16k, go back into the mainloop, immediately wake up because the same fd has more to read, finally back at curl you read another 16k, and back into the mainloop ... and round and round and round.

That is the scenario is the current behavior of curl as implemented in webkit without this patch.

You can significantly reduce cpu time spend in the case of a fast server by reading in a loop until EWOULDBLOCK and not in a loop by going all the way back into the mainloop every time. That was the reason for my remark.

hope this helps, good luck!
-Onne

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.