On 11.11.2010 00:39, Levente Uzonyi wrote:
On Thu, 11 Nov 2010, Levente Uzonyi wrote:
On Tue, 9 Nov 2010, Philippe Marschall wrote:
On 09.11.2010 07:58, Schwab,Wilhelm K wrote:
What does your patch do?
It replaces the #& with and #and: swaps receiver and argument to preserve the same semantics. That saves a primitive call if the data is already sent. It's basically the same as posted by Levente.
At a minimum, it deserves a little attention. Things that come to mind are that one version does less work due to some type of optimization (and runs faster as a result) or that one is too quick to detect a loss of connection and sends less data per opportunity, appearing to run slower as a result.
Can you elaborate on "I'm able to push about 1 Mbyte/s more"? I guess I'm asking how that manifests itself? Are there a bunch of connections that form, send and fail? Do they each get a little farther or do they go faster?
Throughput outgoing from the Pharo image was about 1 Mbyte/s higher. Now
1MB/s throughput sounds pretty low. On windows I could transfer 160MB/s using two processes in the same image by directly using the Socket primitives in 4k chunks. With high level methods (#sendData: #receiveData:) it went down to 110MB/s. With a two image setup (client-server) I got 66MB/s (one CPU/image).
Looks like I missed the word "higher" in your mail. Anyway, I'm interested in your absolute numbers too.
See the attachment. Note that this benchmark is a lie, you're unlikely to see this performance in actual production code. It's a simple Seaside request handler that just writes a 16 Kbyte byte array to the response. In fact it's the source of www.seaside.st. No rendering, no encoding, no sessions, no backtracking, no continuations. You can find the code AJP-Tests-Core in the ajp project on SqueakSource. This is done on an old Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz, 64bit Linux 2.6.35, Cog r2316 and Pharo 1.1.1. Cheers Philippe