-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Improve compression of TastyString #5307
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
Improve compression of TastyString #5307
Conversation
Improves scala#3877 `'{ { val y = ~x * ~x; ~powerCode(n / 2, '(y)) } }` was reduced from 206 bytes to 172 bytes `'{ ~x * ~powerCode(n - 1, x) }` was reduced from 143 bytes to 128 bytes
48b1452
to
a3a41bb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we bump the TASTY version?
i += 1 | ||
def pickle(bytes: Array[Byte]): Pickled = { | ||
val str = new String(Base64.getEncoder().encode(bytes), UTF_8) | ||
def split(sliceEnd: Int, acc: List[String]): List[String] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a reimplementation of sliding
? If so why not str.sliding(maxStringSize, maxStringSize).toList
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This version is more efficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My personal opinion is to go with the simplest solution unless it is performance sensitive and it happen to be a hotspot. No strong feelings though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will change it to the sliding. We can always change it later if needed.
This does not affect the tasty format. We do not need to update the version number. |
I don't know what the policy wrt bumbing the Tasty version is. Say you have two PR's and they each bump the version from 11 to 12. Then what is the right version? Alternatively, could we bump the TASTY version only for each release if there is a change in TASTY? That would limit the bumping speed to at most one every 6 weeks or so. I am not sure what scheme is preferable. What do others think? |
Regardless of the Tasty version bumping scheme, this PR does not need a tasty version bump. Maybe I should add a version to the scheme used to serialize tasty bytes into strings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
i += 1 | ||
def pickle(bytes: Array[Byte]): Pickled = { | ||
val str = new String(Base64.getEncoder().encode(bytes), UTF_8) | ||
def split(sliceEnd: Int, acc: List[String]): List[String] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My personal opinion is to go with the simplest solution unless it is performance sensitive and it happen to be a hotspot. No strong feelings though
Improves #3877
'{ { val y = ~x * ~x; ~powerCode(n / 2, '(y)) } }
was reduced from 206 bytes to 172 bytes
'{ ~x * ~powerCode(n - 1, x) }
was reduced from 143 bytes to 128 bytes