Description
Think aloud here...
PR #708 tries to fit a message in a buffer; this is expensive because of compression when calling the Len() function on a message.
Len() in general is expansive because it goes over the entire message looking for compression points, so O(n) and it needs a map to store all that info, so it generates garbage as well.
What if we cached the length and map in Msg... If you are just adding RR(sets) we only need to count the new ones. This only works if you layer and message correctly; i.e answer first and authority and then a potential additional. Just would make Len() a lot cheaper. Of course it can be called Len() so we need something else, CachedLen().
I think this can even work if you remove RRs, at least if you start at the end; the only difficulty there is know how long the RR will be because it may have been compressed (meaning you need to do some lookups). Removing from the ends works because compression pointers can only point forward.