Advice on fast vs slow types

[jgoodall]

The Readme notes that speed improvements will "depending on the structure". What data types will see the most or least improvements?

[pquerna]

Pretty much all basic types and structs will hit the 2-3x performance gain. I'm always looking for real world examples to add to the built in benchmarks, so if you have a good example structure you can share that would be great.

Known areas of weakness:

Marshal:

• [x] Interface types: When a struct contains an Interface member, there isn't a viable way to detect the underlying type, and therefore ffjson always falls back to encoding/json.
• [x] Map types: Currently falling back. Easy opportunity for a PR.
• [x] Float32 and Float64 currently require a temporary allocation that could be removed by porting strconv.AppendFloat to using a byte.Buffer.
• [ ] Size Estimation: Reducing GC churn is one the best ways to improve performance at this point, so estimating the size of the required buffer at the start of ffjson has a good ROI -- today there is a simple implementation in getTypeSize, but if you have on average strings larger than 32 bytes, it'll mean more allocations than needed.
• [x] Improved handling of OmitEmpty: If there are no Omit Empty members, it is possible to improve the generated code, removing the use of the .Rewind and writing comas.

Unmarshal:

• [ ] Map types are currently falling back to encoding/json.
• [ ] Large strings could be made faster by using SSE4.2's string functions to find the end of the string.

[klauspost]

Also, it should be possible to string together multiple buf.WriteString:

    buf.WriteString(`{`)
    buf.WriteString(`"message":`)

Should be able to become:

    buf.WriteString(`{"message":`)

Nothing big, but it avoids: 2 function calls (I assume copy() is inlined), 1 buffer size check (in buf.grow), one re-slice (grow), 1 copy operation.

[pquerna]

@klauspost To do that consistently, I think I'd have to move to more of an AST-style representation and then have an optimization pass to merge WriteString calls.

[klauspost]

I think we have coverered the issues now in the documentation, so I will close this issue.