1. 19 Jan, 2023 1 commit
  2. 18 Jan, 2023 3 commits
  3. 17 Jan, 2023 1 commit
  4. 16 Jan, 2023 1 commit
  5. 13 Jan, 2023 1 commit
  6. 03 Jan, 2023 1 commit
  7. 31 Dec, 2022 2 commits
  8. 15 Dec, 2022 2 commits
  9. 13 Dec, 2022 1 commit
  10. 12 Dec, 2022 1 commit
  11. 08 Dec, 2022 4 commits
    • David Fifield's avatar
      Take ownership of buffer in QueuePacketConn QueueIncoming/WriteTo. · 839d2218
      David Fifield authored
      This design is easier to misuse, because it allows the caller to modify
      the contents of the slice after queueing it, but it avoids an extra
      allocation + memmove per incoming packet.
      
      Before:
      	$ go test -bench='Benchmark(QueueIncoming|WriteTo)' -benchtime=2s -benchmem
      	BenchmarkQueueIncoming-4         7001494               342.4 ns/op          1024 B/op          2 allocs/op
      	BenchmarkWriteTo-4               3777459               627 ns/op            1024 B/op          2 allocs/op
      After:
      	$ go test -bench=BenchmarkWriteTo -benchtime 2s -benchmem
      	BenchmarkQueueIncoming-4        13361600               170.1 ns/op           512 B/op          1 allocs/op
      	BenchmarkWriteTo-4               6702324               373 ns/op             512 B/op          1 allocs/op
      
      Despite the benchmark results, the change in QueueIncoming turns out not
      to have an effect in practice. It appears that the compiler had already
      been optimizing out the allocation and copy in QueueIncoming.
      #40187
      
      The WriteTo change, on the other hand, in practice reduces the frequency
      of garbage collection.
      #40199
      839d2218
    • David Fifield's avatar
    • David Fifield's avatar
      Have SnowflakeClientConn implement io.WriterTo. · 77b186ae
      David Fifield authored
      By forwarding the method to the inner smux.Stream. This is to prevent
      io.Copy in the top-level proxy function from allocating a buffer per
      client.
      
      The smux.Stream WriteTo method returns io.EOF on success, contrary to
      the contract of io.Copy that says it should return nil. Ignore io.EOF in
      the proxy loop to avoid a log message.
      
      /anti-censorship/pluggable-transports/snowflake/-/issues/40177
      77b186ae
    • David Fifield's avatar
      Manually unlock the mutex in ClientMap.SendQueue. · 64491466
      David Fifield authored
      Rather than use defer. It is only a tiny amount faster, but this
      function is frequently called.
      
      Before:
      	$ go test -bench=BenchmarkSendQueue -benchtime=2s
      	BenchmarkSendQueue-4    15901834               151 ns/op
      After:
      	$ go test -bench=BenchmarkSendQueue -benchtime=2s
      	BenchmarkSendQueue-4    15859948               147 ns/op
      
      #40177
      64491466
  12. 03 Dec, 2022 1 commit
  13. 02 Dec, 2022 2 commits
  14. 01 Dec, 2022 1 commit
  15. 29 Nov, 2022 3 commits
  16. 28 Nov, 2022 5 commits
  17. 23 Nov, 2022 2 commits
  18. 21 Nov, 2022 1 commit
  19. 17 Nov, 2022 1 commit
    • Cecylia Bocovich's avatar
      Add gofmt output to CI test before calling test -z · 115ba6a7
      Cecylia Bocovich authored
      We use a call to test -z together with go fmt because it doesn't output
      a non-zero exit status (triggering CI test failure). However, we lose
      useful debugging output from the go fmt call because test -z swallows
      it. This adds very verbose formatting output to the CI test.
      115ba6a7
  20. 16 Nov, 2022 6 commits
    • David Fifield's avatar
      Benchmark for encapsulation.ReadData. · e851861e
      David Fifield authored
      e851861e
    • David Fifield's avatar
      a579c969
    • David Fifield's avatar
      Benchmark websocket.Conn Upgrade creation. · 4ae63ecc
      David Fifield authored
      I had thought to set a buffer size of 2048, half the websocket package
      default of 4096. But it turns out when you don't set a buffer size, the
      websocket package reuses the HTTP server's read/write buffers, which
      empirically already have a size of 2048.
      
      	$ go test -bench=BenchmarkUpgradeBufferSize -benchmem -benchtime=5s
      	BenchmarkUpgradeBufferSize/0-4                     25669            234566 ns/op           32604 B/op        113 allocs/op
      	BenchmarkUpgradeBufferSize/128-4                   24739            238283 ns/op           24325 B/op        117 allocs/op
      	BenchmarkUpgradeBufferSize/1024-4                  25352            238885 ns/op           28087 B/op        116 allocs/op
      	BenchmarkUpgradeBufferSize/2048-4                  22660            234890 ns/op           32444 B/op        116 allocs/op
      	BenchmarkUpgradeBufferSize/4096-4                  25668            232591 ns/op           41672 B/op        116 allocs/op
      	BenchmarkUpgradeBufferSize/8192-4                  24908            240755 ns/op           59103 B/op        116 allocs/op
      4ae63ecc
    • David Fifield's avatar
      Hoist temporary buffers outside the loop. · 2321642f
      David Fifield authored
      Otherwise the buffers are re-allocated on every iteration, which is a
      surprise to me. I thought the compiler would do this transformation
      itself.
      
      Now there is just one allocation per client←server read (one
      messageReader) and two allocations per server←client read (one
      messageReader and one messageWriter).
      
      	$ go test -bench=BenchmarkReadWrite -benchmem -benchtime=5s
      	BenchmarkReadWrite/c←s_150-4              481054             12849 ns/op          11.67 MB/s           8 B/op          1 allocs/op
      	BenchmarkReadWrite/s←c_150-4              421809             14095 ns/op          10.64 MB/s          56 B/op          2 allocs/op
      	BenchmarkReadWrite/c←s_3000-4             208564             28003 ns/op         107.13 MB/s          16 B/op          2 allocs/op
      	BenchmarkReadWrite/s←c_3000-4             186320             30576 ns/op          98.12 MB/s         112 B/op          4 allocs/op
      2321642f
    • David Fifield's avatar
      Use io.CopyBuffer in websocketconn.readLoop. · 264425a4
      David Fifield authored
      This avoids io.Copy allocating a 32 KB buffer on every call.
      https://cs.opensource.google/go/go/+/refs/tags/go1.19.1:src/io/io.go;l=416
      
      	$ go test -bench=BenchmarkReadWrite -benchmem -benchtime=5s
      	BenchmarkReadWrite/c←s_150-4              385740             15114 ns/op           9.92 MB/s        4104 B/op          3 allocs/op
      	BenchmarkReadWrite/s←c_150-4              347070             16824 ns/op           8.92 MB/s        4152 B/op          4 allocs/op
      	BenchmarkReadWrite/c←s_3000-4             190257             31581 ns/op          94.99 MB/s        8208 B/op          6 allocs/op
      	BenchmarkReadWrite/s←c_3000-4             163233             34821 ns/op          86.16 MB/s        8304 B/op          8 allocs/op
      264425a4
    • David Fifield's avatar
      Call WriteMessage directly in websocketconn.Conn.Write. · 3df514ae
      David Fifield authored
      In the client←server direction, this hits a fast path that avoids
      allocating a messageWriter.
      https://github.com/gorilla/websocket/blob/v1.5.0/conn.go#L760
      
      Cuts the number of allocations in half in the client←server direction:
      
      	$ go test -bench=BenchmarkReadWrite -benchmem -benchtime=5s
      	BenchmarkReadWrite/c←s_150-4              597511             13358 ns/op          11.23 MB/s       33709 B/op          2 allocs/op
      	BenchmarkReadWrite/s←c_150-4              474176             13756 ns/op          10.90 MB/s       34968 B/op          4 allocs/op
      	BenchmarkReadWrite/c←s_3000-4             156488             36290 ns/op          82.67 MB/s       68673 B/op          5 allocs/op
      	BenchmarkReadWrite/s←c_3000-4             190897             34719 ns/op          86.41 MB/s       69730 B/op          8 allocs/op
      3df514ae