String#clear keep the string capacity

[casperisfine]

[Feature #17790] https://bugs.ruby-lang.org/issues/17790

This is useful when trying to efficiently re-use a buffer, and is consistent with Array#clear.

[dylanahsmith]

is consistent with Array#clear

It doesn't look like Array#clear does keep the capacity (

ruby/array.c

Lines 4554 to 4556 in ff43ecc

	if (ARY_DEFAULT_SIZE * 2 < ARY_CAPA(ary)) {
	ary_resize_capa(ary, ARY_DEFAULT_SIZE * 2);
	}

)

[casperisfine]

It doesn't look like Array#clear does keep the capacity

Interesting, I actually didn't think to check the implementation. So apparently Array#clear shink the capacity of if it's larger than 32. Hence why my experimentation suggested the capacity was preserved.

[ioquatix]

This is an interesting issue.

Given that users can choose between:

thing.clear

thing = thing.class.new

I believe it's reasonable that thing.clear retains any existing buffers/allocations.

This would be consistent with the typical use cases - buffers, etc, where the string/array/thing would be reused with the similar amount of data.

The only case where it might not be realistic is when thing.clear is used to immediately release memory.

[casperisfine]

The only case where it might not be realistic is when thing.clear is used to immediately release memory.

Yes, that's what I'm worried of.

Also the idea is to be able to empty the string (or array or hash for that matter) while still retaining its capacity to reuse it.

But I agree with some of the concerns raised. To do this safely you might often need to be able to query that capacity to decide wether you'd rather shrink it or not.

So maybe what would be needed would be String#capacity and String#capacity=.

[ioquatix]

My feeling is 99% of these problems happen because we try to use strings for binary buffers.

This problem has been going around in circles for a long time (at least several years).

Honestly, not sure what the solution is - my last attempt to solve this was to treat strings with binary encoding differently (assumption that it's a data buffer). The implication in this issue would be that if the string was binary encoded, string.clear would not resize the buffer.

If you wanted to be more generic:

string.clear(free: true/false)

That being said, I can imagine tons of use cases where string.clear would benefit from not releasing memory. Maybe we need a benchmark?

[dylanahsmith]

I don't see why the encoding matters, since non-binary encoded strings could still be used as a buffer with mutable strings.

free: should not be used as a parameter name for changing the capacity, since with a variable width object allocation implementation we could store the string as part of the same allocation, in which case it would be reallocating. The concept of shrinking the capacity seems more appropriate by making less of an implication about the internals.