Aliaksandr Valialkin

It's very difficult to implement byte buffer pooling that satisfies all the needs. `butebufferpool` isn't a silver bullet yet. It performs better than a dumb `sync.Pool` when working with variously-sized...

I'm OK with the migration. The only drawback is that it can break existing codebases with github.com/valyala/fasthttp imports. The main question is: which problems will the migration solve? On Wed,...

We need to check that nothing breaks after the migration: - Old go imports `github.com/valyala/fasthttp` should continue working. - `go mod` should seamlessly work with old and new paths (`github.com/fasthttp/fasthttp`)....

`fastjson` isn't intended for parsing large JSONs. It would be better using something like [jstream](https://github.com/bcicen/jstream) for this use case.

Unfortunately this won't work as expected, since the returned string will contain garbage after the next call to `Parser.Parse`, since `v.s` is backed by byte slice, which is modified on...

Either stick to `string(v.GetStringBytes())` or use something unsafe like `toUnsafeString(v.GetStringBytes())` if you know possible consequences of improper usage of the returned unsafe string.

This is great idea, since it requires less RAM when parsing JSON structs with non-constant structure, but it slows down parsing a bit. I tried playing with this PR in...

This won't work, since `v.s` is backed by byte slice, which changes on the next `Parser.Parse` call. This means that the returned string contents will become garbage on the next...

If `fastjson` builds under go 1.10, then it should work there.

@nikolaslaolao , could you provide the code that doesn't work as expected?