Large optimization to unpickler

[Theelx]

I realized that in certain cases, actually a sizeable number of cases, we don't need to check if it has a tag because it's a float, or an int, or something else that can't contain a string tag. This doubles the speed of unpickling for my personal use case (which involves a large amount of ints/floats), and should provide a statistically significant speed increase for most other cases also.

[davvid]

Sweet, thanks!

[Theelx]

No problem! I was looking over encoder optimizations recently, do you think I should focus more on optimizing encoding or decoding?

[davvid]

Hmm that's a great question. I'm not really sure which has the most low-hanging fruit. decode() performance might benefit more users would be my guess. For example, an app that stores state may read it more often then it stores it, but like most things it's fairly app specific.

There's a bunch of backwards-compatibility code around the self._namestack, self._namedict and self._refname() in support of the older tags.REF stuff that was emitted by much older versions. There's already enough stuff since v1.5.0 that we can tag v1.5.1 shortly to clear the way for another minor (v1.6.0) that drops that backwards-compatibility support for tags.REF if it improves performance even further.

[Theelx]

Just profiled that backwards-compatibility code, it doesn't seem to take up much cpu time or memory so I think I'll leave it for now.

Edit: We should also consider that according to SemVer 2.0, we can only break backwards compatibility when incrementing major versions, so 2.0.0 would be more appropriate if we were to take out support for tags.REF.