Birdwatcher performance is suboptimal

[hellerve]

As detailed in ecix/birdseye#6, the performance of the birdwatcher on big queries is suboptimal. I will measure how much of that is bird and how much comes from our parsing and treatment. Go's JSON performance is pretty bad, so maybe we should think of measuring that as well.

[annikahannig]

I merged the gzip support and testet it.
However, the flask backend required for the frontend, renders (at least in my env) an ungziped version of the result.

We have to add the support for this in there too, I guess.

[hellerve]

That is of course true, this is due to the proxy in done in the flask app. Flask should have the capability to gzip responses out of the box, we'll just need to enable it.

[annikahannig]

That's what I thought. I'm looking into this tomorrow :)

[ugorji]

Try github.com/ugorji/go/codec for a faster json implementation (slightly faster on encode, 3X faster on decode, while using significantly less memory/allocations. My raw results from doing a large decode is below:

Benchmark__Json_______Encode-8         	   10000	    158715 ns/op	    2433 B/op	      22 allocs/op
Benchmark__Std_Json___Encode-8         	   10000	    167512 ns/op	  122912 B/op	     257 allocs/op
-------------------------------
Benchmark__Json_______Decode-8         	   10000	    225814 ns/op	   49225 B/op	     469 allocs/op
Benchmark__Std_Json___Decode-8         	    2000	    668774 ns/op	   83800 B/op	    2121 allocs/op