Avoid using defer statements on time-sensitive function calls.

[qpfiffer]

Was reading this thread when somebody mentioned that using defer is slower than explicitly unlocking, so I did a small rewrite and ran some tests of my own:

 # With deferred unlock on unjar:
./wrk -t2 -c400 -d10s http://localhost:38080/x/x
Running 10s test @ http://localhost:38080/x/x
  2 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.75s     1.15s    4.63s    80.96%
    Req/Sec    47.23     23.61    95.00     69.23%
  898 requests in 10.02s, 105.23KB read
  Socket errors: connect 0, read 0, write 0, timeout 669
Requests/sec:     89.63
Transfer/sec:     10.50KB

# Removed deferred unlock on unjar:
./wrk -t2 -c400 -d10s http://localhost:38080/x/x
Running 10s test @ http://localhost:38080/x/x
  2 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.28s     1.33s    4.63s    63.00%
    Req/Sec    51.55     15.58    88.00     75.00%
  1092 requests in 10.02s, 127.97KB read
  Socket errors: connect 0, read 0, write 0, timeout 729
Requests/sec:    109.01
Transfer/sec:     12.77KB

Sure enough, the lack of defer is faster. I'll leave this open for a little while for any comments on why we should use defer or otherwise. Code review as well would be awesome.

[Xe]

You should open a thread on golang/go.

[qpfiffer]

@Xe It makes sense to me, since defer will happen regardless of exceptions/panics/whatever they're called in go.

[qpfiffer]

http://lk4d4.darth.io/posts/defer/

I'm going to merge this in because this is a known thing in Golang. Besides, if we're throwing Errors or whatever from the C API then things are royally fucked anyway.