Make accept use minimal_dispatch

[ry]

this branch

~/src/deno> ./third_party/wrk/mac/wrk -d 20 http://localhost:4500/
Running 20s test @ http://localhost:4500/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   263.62us  450.37us   8.45ms   96.34%
    Req/Sec    23.98k     1.81k   28.68k    81.34%
  958979 requests in 20.10s, 46.64MB read
Requests/sec:  47706.68
Transfer/sec:      2.32MB

master

~/src/deno> ./third_party/wrk/mac/wrk -d 20 http://localhost:4500/
Running 20s test @ http://localhost:4500/
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   275.87us  490.25us   8.07ms   96.30%
    Req/Sec    23.20k     2.06k   27.56k    72.14%
  928345 requests in 20.10s, 45.15MB read
Requests/sec:  46182.19
Transfer/sec:      2.25MB

Here are the benchmark results from travis:

  "req_per_sec": {
    "node": 31492, 
    "deno_core_single": 76514, 
    "hyper": 96890, 
    "deno_core_multi": 84595, 
    "deno_net_http": 19265, 
    "deno": 70378, 
    "node_tcp": 81977
  }, 
  "max_latency": {
    "node": 11.74, 
    "deno_core_single": 8.22, 
    "hyper": 5.12, 
    "deno_core_multi": 10.15, 
    "deno_net_http": 14.99, 
    "deno": 13.6, 
    "node_tcp": 12.1
  }, 

[piscisaureus]

I don't see a significant difference in performance, plus this is a regression in the sense that error information is lost.
So I'm -1 for now.

[piscisaureus]

^

[ry]

@piscisaureus This takes flatbuffers completely out of the loop for tests/http_bench.ts which allows us to focus on the remaining bottlenecks. Without thinking thru the logic of the server is difficult.

The error codes will be dealt with eventually - I think the regression is worth it

[ry]

nevermind. the accept isn't in the hot loop for test/http_bench.ts I will put this off until we have a more established minimal dispatch