assuming this is correct, could this be optimized? https://pl.kotl.in/BKCVGjs_8

pre-size string builder to known final length

what do you mean by that

if the string is 10 characters long and you're padding out to 40 characters, it'd be best to pre-size the string builder to 40, append string, append spaces, and call toString(). This ensures the backing character array never has to expand to accommodate the padding

Using the

ensureCapacity

you asked about earlier nvm, there's a constructor parameter too of course.

like this?

fun String.padExtendEnd(to: Int, char: Char) = this.toStringBuilder().append(char.toString().repeat(to-this.length)).toString()

Like this:

import kotlin.math.max

fun String.padExtendEnd(to: Int): String {
    val build = StringBuilder(max(this.length, to));
    build.append(this);
    while(build.length != to) build.append(' ')
    return build.toString()
}

hmmm ok

Well it creates another

String

instance, which is dumb since you already have a new temporary array in the

StringBuilder

.

ok, the capacity thing is only available on Kotlin/Native right?

No.

oh

I think that's just an oversight, they should probably add it to the Kotlin stdlib.

is StringBuilder(this) faster than StringBuilder().append(this)

depends on the length of

this

and whether it causes expansion

@jw so in which cases are each faster than the other?

if the string is less than 16 characters they are equally as fast but the former allocates more than the latter. if its more than 16 characters the former is faster and the latter allocates more

Interestingly enough the stdlib does't do the

max

thing, I wonder if I'm wrong with that?

ok

Your question doesn't make sense, no.

if

padExtendEnd

extends the end to

to

when it is larger then

this.length

specifying a value lower than

this.length

should do the opposite (in which as pads from the end

right

untill

to

characters remain) right? if so should the same apply for

padExtendStart

but in the other direction?

Usually

pad

functions don't work like this, eg. the ones in Kotlin don't.

oh

I don't think it can be optimized any more.

ok