Hi,
I have an app where about half of the alloc space is coming from _, err = out.UnmarshalMsg(b) (where b is a pre-existing byteslice i want to decode) and it's triggering GC too much.

I have read https://github.com/tinylib/msgp/wiki/Getting-Started a couple times, specifically the section on the Marshaler and Unmarshaler interfaces. The former is pretty clear but i'm struggling with the latter. it's described as "simply the converse" and talks about how you can use the return value in a clever way. But it doesn't really mention anything about the input slice. is there anything noteworthy about it? Especially in context of zero-allocation?
For example am i supposed to supply an input slice that uses the len to cover the region of data to decode, but additional cap as temporary space for decoding? Or is it ok for cap to == len because it doesn't really need "temporary" space?

for the record, most of the allocations are seeing are due to ReadStringBytes (#145)
but i'm also seeing some others like

         .          .    308:           if cap(z.Tags) >= int(xsz) {
         .          .    309:               z.Tags = z.Tags[:xsz]
         .          .    310:           } else {
  205.70MB   205.70MB    311:               z.Tags = make([]string, xsz)
         .          .    312:           }

...
        .          .    416:    if cap((*z)) >= int(xsz) {
         .          .    417:       (*z) = (*z)[:xsz]
         .          .    418:   } else {
   52.49MB    52.49MB    419:       (*z) = make(MetricDataArray, xsz)
         .          .    420:   }
...
         .          .    429:           if (*z)[ajw] == nil {
     958MB      958MB    430:               (*z)[ajw] = new(MetricData)
         .          .    431:           }

which i wonder if they can be avoided?

(this is while unmarshaling a MetricDataArray, which is defined in https://github.com/raintank/raintank-metric/blob/master/schema/metric.go)

thanks!