Skip to content

Commit

Permalink
Showing 1 changed file with 0 additions and 32 deletions.
Original file line number Diff line number Diff line change
@@ -680,38 +680,6 @@ public static boolean bothSingleByteOptimizable(DynamicObject string, DynamicObj
}
}

@CoreMethod(names = "chop!", raiseIfFrozenSelf = true)
@ImportStatic(StringGuards.class)
public abstract static class ChopBangNode extends CoreMethodArrayArgumentsNode {

@Child private RopeNodes.MakeSubstringNode makeSubstringNode;

public ChopBangNode(RubyContext context, SourceSection sourceSection) {
super(context, sourceSection);
makeSubstringNode = RopeNodesFactory.MakeSubstringNodeGen.create(context, sourceSection, null, null, null);
}

@Specialization(guards = "isEmpty(string)")
public DynamicObject chopBangEmpty(DynamicObject string) {
return nil();
}

@Specialization(guards = "!isEmpty(string)")
public Object chopBang( DynamicObject string) {
final int newLength = choppedLength(string);

StringOperations.setRope(string, makeSubstringNode.executeMake(rope(string), 0, newLength));

return string;
}

@TruffleBoundary
private int choppedLength(DynamicObject string) {
assert RubyGuards.isRubyString(string);
return StringSupport.choppedLength19(StringOperations.getCodeRangeableReadOnly(string), getContext().getJRubyRuntime());
}
}

@CoreMethod(names = "count", rest = true)
@ImportStatic(StringGuards.class)
public abstract static class CountNode extends CoreMethodArrayArgumentsNode {

2 comments on commit 699ee62

@nirvdrum
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chrisseaton Changes like this are how I think we'll make it easier for long-lengthed ropes. We could have specialized various cases here, but doing that across the board for every operation is going to be messy. Whereas the Ruby implementation of String#chop! doesn't care about int vs long and doesn't need to fetch all the bytes from the rope. Note this also required an improvement in the string_previous_byte_index primitive in 36bae36 to be efficient. The result is a more rope-friendly implementation (the previous one was more byte array friendly).

This doesn't fix everything, but we should be on the lookout for opportunities like this. Fortunately, it fits in with the more general philosophy of tight primitives and then moving operations out to Ruby.

Sorry, something went wrong.

@chrisseaton
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, more in Ruby where it doesn't damage performance is almost always the right thing to do.

Sorry, something went wrong.

Please sign in to comment.