fix: Small perf improvement to generate_r

[fbogsany]

This is a small performance improvement to the generate_r method for the consistent-probability sampler. This method generates a r value from the trace_id. The current implementation unnecessarily allocates a slice of the trace_id string. Using the offset: argument to unpack1, we can avoid this allocation.

Benchmark results:

Calculating -------------------------------------
          generate_r      3.920M (± 0.4%) i/s -     19.654M
 generate_r_in_place      4.596M (± 0.5%) i/s -     23.085M

Comparison:
 generate_r_in_place:  4595613.7 i/s
          generate_r:  3920215.1 i/s - 1.17x slower

[casperisfine]

Not sure if you are aware but offset was added in 3.1, and IIRC otel is supposed to be compatible with Ruby 3.0?

But since the offset is static here, you can use the @ syntax:

>> "abcedfghsdfdsfhdsfjsdkjfdsjfkdlsfjdsfjksdfk".unpack1('Q>', offset: 8)
=> 8314883393651632228
>> "abcedfghsdfdsfhdsfjsdkjfdsjfkdlsfjdsfjksdfk".unpack1('@8Q>')
=> 8314883393651632228

offset was added to avoid allocating a new pattern string every time when the offset is dynamic.

[casperisfine]

Not sure if you are aware but offset was added in 3.1, and IIRC otel is supposed to be compatible with Ruby 3.0?

But since the offset is static here, you can use the @ syntax:

>> "abcedfghsdfdsfhdsfjsdkjfdsjfkdlsfjdsfjksdfk".unpack1('Q>', offset: 8)
=> 8314883393651632228
>> "abcedfghsdfdsfhdsfjsdkjfdsjfkdlsfjdsfjksdfk".unpack1('@8Q>')
=> 8314883393651632228

offset was added to avoid allocating a new pattern string every time when the offset is dynamic.