Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Data analysts should be able to reverse strings using
Text.reverse
#3377Data analysts should be able to reverse strings using
Text.reverse
#3377Changes from 1 commit
7b283f3
221a588
2b9425f
b6b004f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Using a
StringBuilder
works, but I'm wondering if using our+
wouldn't be more idiomatic - for example ourVector.join
does in fact use+
.Performance-wise it should be quite comparable, because our
+
uses ropes under the hood to achieve O(1) amortized append time. Still, probablyStringBuilder
has a bit less of an overhead, so likely still a bit faster.So I'm not really saying to change it - because this definitely works and is fast, but wondering what best practices we should adopt - because I think it would be good to have consistent approach to this between this function,
Vector.join
and possibly other ones.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.
Yes, Text ropes cache collapsed strings - see
ToJavaStringNode::inplaceFlatten
.As for
Vector.join
- I'm talking about the function which concatenates a vector of texts into a single text, did you meanVector.+
instead?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.
Idiomatically,
+
does seem like the right choice.When I was implementing this, I actually did compare both approaches and the
+
was ~2-3x slower for a 10000 length string. Though that may be due to me making some other error in the implementation. I can re-draft that benchmark and include it in the PR if you'd like to compare for yourself. I didn't include the benchmark in the commit because it didn't seem like this is something likely to change, performance-wise, over time.Not sure if I follow the
Vector.join
andVector.+
comments.StringBuilder
impl:+
impl:Naive
(StringBuilder.new this).reverse
(not really a fair comparison because not extended-grapheme-cluster-aware):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.
@radeusgd ping ^
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.
Hmm, then I think you are right that it may be better to keep the stringbuilder. I guess the difference is because the ropes still have some more allocation overhead.
As for
Vector.join
andVector.+
- no worry it was a reply to a later deleted comment, please ignore 😅