[generator.c] Use RB_ENC_CODERANGE to check the cached coderange before calling rb_enc_str_coderange

[samyron]

This PR introduces a function json_str_coderange to first check the cached coderange via RB_ENC_CODERANGE before calling rb_enc_str_coderange.

As per the samply profiler when profiling activitypub.json, we can see we're spending 3.1% of the time in rb_enc_str_coderange.

The code is spending almost all of the time in the early exit path + returning to the caller:

It could be possible this is just an artifact of the benchmark. We load the activitypub.json once, then constantly generate JSON. After the first scan, every string should have it's coderange known. I'm not sure if this holds in general though.

I did find pretty much the same code in re.c - str_coderange.

Benchmarks

Benchmarks run on an M1 Macbook Air.

== Encoding activitypub.json (52595 bytes)
ruby 3.4.8 (2025-12-17 revision 995b59f666) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
               after     2.840k i/100ms
Calculating -------------------------------------
               after     28.777k (± 1.7%) i/s   (34.75 μs/i) -    144.840k in   5.034576s

Comparison:
              before:    27075.2 i/s
               after:    28777.2 i/s - 1.06x  faster


== Encoding citm_catalog.json (500298 bytes)
ruby 3.4.8 (2025-12-17 revision 995b59f666) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
               after   141.000 i/100ms
Calculating -------------------------------------
               after      1.419k (± 1.1%) i/s  (704.61 μs/i) -      7.191k in   5.067439s

Comparison:
              before:     1360.1 i/s
               after:     1419.2 i/s - 1.04x  faster


== Encoding twitter.json (466906 bytes)
ruby 3.4.8 (2025-12-17 revision 995b59f666) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
               after   299.000 i/100ms
Calculating -------------------------------------
               after      2.954k (± 1.3%) i/s  (338.51 μs/i) -     14.950k in   5.061485s

Comparison:
              before:     2780.3 i/s
               after:     2954.2 i/s - 1.06x  faster


== Encoding ohai.json (20145 bytes)
ruby 3.4.8 (2025-12-17 revision 995b59f666) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
               after     3.783k i/100ms
Calculating -------------------------------------
               after     37.564k (± 3.7%) i/s   (26.62 μs/i) -    189.150k in   5.044004s

Comparison:
              before:    34472.6 i/s
               after:    37564.0 i/s - 1.09x  faster

[byroot]

We load the activitypub.json once, then constantly generate JSON. After the first scan, every string should have it's coderange known. I'm not sure if this holds in general though.

Probably not for all strings, but for some of them, particularly keys, it should yes. Also even for brand new strings, some other code might have calculated the coderange first, given that many string methods do, so I don't think the benchmark is too unrealistic (even though it would be nice if some misses were exercised too, but it would be tricky).

[byroot]

rb_enc_str_coderange should probably be this inline helper. I'll see about making the change upstream.

[byroot]

I'll see about making the change upstream.

ruby/ruby#16771