Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory increasing every Version.String() called #118

Open
kuzuha opened this issue Mar 1, 2023 · 3 comments
Open

Memory increasing every Version.String() called #118

kuzuha opened this issue Mar 1, 2023 · 3 comments

Comments

@kuzuha
Copy link

kuzuha commented Mar 1, 2023

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
Copy link

kke commented Sep 11, 2023

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

@kke
Copy link

kke commented Jan 12, 2024

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
Copy link

kke commented Jan 12, 2024

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

segments [maxSegments]int64
numSegments int

The struct would still be comparable with ==.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants