Memory increasing every Version.String() called

[kuzuha]

Version.String() currently returns every new string from buffer.
Also, Version.Compare calles Version.String() internally.

When I should compare many Versions, every Compare func creates new string.
It requires too many memories, and cases too heavy GC.

I propose result of Version.String() should be cached internally (like original).
How do you think about?

[kke]

I think caching would double the leak when you have many instances and not just repeatedly calling String() on a single instance.

[kke]

I think the main problem is Compare doing v.String() == other.String()

I wonder if it would be more efficient if instead of segments []int64 there would be something like:

  segment1 int64
  segment2 int64
  segment3 int64
  segment4 int64
  segment5 int64
  segment6 int64
  lenSegments int

then equality could be compared with v == other.

This would of course put a limit to how many segments you can have.

[kke]

Actually, ARRAYS of comparable types are comparable. There could therefore be:

segments [maxSegments]int64
numSegments int

The struct would still be comparable with ==.

[radeksimko]

One good way forward here would be raising a PR with some benchmarks that would then allow any proposed changes to be tested, to understand the performance impact.

[Manikkumar1988]

Proposing to use original field of Version struct to do quick equality check as current implmentation as so 8 heap allocation per call to Compare.

Created a PR for the same here