Avoid unnecessary checks when calling readCodePointValue on Buffer

[fzhinkin]

Improves readCodePointValue performance by ~10% when the receiver is Buffer.

Addresses a particular issue uncovered in Kotlin/kotlinx.serialization#2707.

In general, similar issues will be tracked by #342.

Benchmarking results w/ jdk21 on macOS host w/ AS M2 Pro CPU:

• before:

Benchmark                                                (encoding)  (minGap)   Mode  Cnt          Score         Error  Units
Utf8CodePointsBenchmark.benchmark                             ascii       128  thrpt    5  140373273.339 ±  694216.983  ops/s
Utf8CodePointsBenchmark.benchmark                              utf8       128  thrpt    5   87815553.220 ± 1128003.103  ops/s
Utf8CodePointsBenchmark.benchmark                            sparse       128  thrpt    5  127022106.163 ± 2328819.676  ops/s
Utf8CodePointsBenchmark.benchmark                            2bytes       128  thrpt    5  114376689.982 ± 1040653.731  ops/s
Utf8CodePointsBenchmark.benchmark                            3bytes       128  thrpt    5   97996115.414 ±  943350.071  ops/s
Utf8CodePointsBenchmark.benchmark                            4bytes       128  thrpt    5   90219791.071 ± 1057392.878  ops/s
Utf8CodePointsBenchmark.benchmark                               bad       128  thrpt    5  129320612.342 ± 1542655.859  ops/s

• after:

Benchmark                                                (encoding)  (minGap)   Mode  Cnt          Score         Error  Units
Utf8CodePointsBenchmark.benchmark                             ascii       128  thrpt    5  141722288.764 ± 1297310.006  ops/s
Utf8CodePointsBenchmark.benchmark                              utf8       128  thrpt    5   96539014.741 ±  397371.538  ops/s
Utf8CodePointsBenchmark.benchmark                            sparse       128  thrpt    5  136350281.578 ± 9488253.150  ops/s
Utf8CodePointsBenchmark.benchmark                            2bytes       128  thrpt    5  126114440.572 ± 2201911.847  ops/s
Utf8CodePointsBenchmark.benchmark                            3bytes       128  thrpt    5  110880125.804 ± 1953517.672  ops/s
Utf8CodePointsBenchmark.benchmark                            4bytes       128  thrpt    5  101067180.434 ± 1928563.268  ops/s
Utf8CodePointsBenchmark.benchmark                               bad       128  thrpt    5  146300685.623 ± 2768473.597  ops/s

[lppedd]

@fzhinkin question, would this be a valid solution to avoid an is check?

public fun Buffer.readCodePointValue(): Int {
  return commonReadUtf8CodePoint()
}

public fun Source.readCodePointValue(): Int { 
  ... 
}

[fzhinkin]

No, it wouldn't, as extension functions are resolved statically based on the declared receiver's type.

So if there's a code like

val src: Source = Buffer().apply { ... }
println(src.readCodePointValue())

readCodePointValue will be resolved to Source.readCodePointValue and an extension defined on Buffer won't help.

[lppedd]

@fzhinkin thanks! If we have the additional extension function tho, it will avoid the check when the type is Buffer, which I think is the most common case.

[fzhinkin]

it will avoid the check when the type is Buffer, which I think is the most common case.

Indeed, at least for Okio, the corresponding function is invoked on Buffer more frequently, compared to BufferedSource.

I don't really like the idea of adding an extra extension function, as performance benefits should be neglectingly small. On the other hand, there will be some benefits, so I consider adding the function later in the course of #342.

[lppedd]

Thanks! I think the best approach would be to do the same thing you did for unsafe operations, throw in a quick kotlinx-benchmark. Would be interesting to document all of these cases for JS.

For K/JS here we are lucky because Buffer is a class, and the is check will be compiled to a native instanceof. When the check is done on an interface, there is a lot more work involved.