Melons and Pumpkins grow more slowly than in Java Edition

I'm having a similar problem. Pumpkins are growing very, very slowly. I am using v1.16.10 on iOS, (iPhone). To test it, I created a new flat world, and planted 64 pumpkin seeds in 4 rows of 16 each, all within one chunk. I turned it to "always day" and turned off weather cycling. There were only a half dozen pumpkins after 2 hours, and after 4 hours, only 2/3rd of the seeds had grown into pumpkins. See attached photo.

Code Analysis

Plant growth speed is based on the area around the plant/stem. The maximum growth speed is 10.0. In Java Edition, the probability of growth is

1/(floor(25/points) + 1)

where points is the growth speed. For maximal growth farmland, this works out to be 0.33 chance of growing per random tick to the plant, or 1/4096 chance per game tick. However, because random tick speed defaults to 3 on java and 1 on Bedrock, a 0.33 chance of growing per random tick to the plant is a 1/12288 chance of growth per game tick on Bedrock.

To compensate for this difference, crops on Bedrock like wheat, but not StemBlocks, calculate the probability of growth as

min(1,1/floor(9/points))

At maximal growth rate, the probability of growth is 1 per random tick to the plant, and 1/4096 chance per game tick, matching Java. However, you will notice that based on this model the growth probability of crops maxes out on bedrock when the growth rate is 5 on bedrock but 9 on Java.

Suggested Change (easy)

Update StemBlock growth rate on Bedrock to match the Crop growth rate.

Suggested Change (better)

The entire growth rate system can be overhauled to improve performance and code quality.

• Avoid floating point arithmetic and calculate growth rate as an integer between 0 and 40 inclusive. This maintains the same precision as before when growth rate was between 0 and 10 with 0.25 increments possible.

• Calculate whether the plant grows as

  rand_int(0,40*default_random_tick_speed) < points

• For additional performance, replace the "rand_int" function with a version the minimizes division, see https://www.pcg-random.org/posts/bounded-rands.html and https://lemire.me/blog/2019/06/06/nearly-divisionless-random-integer-generation-on-various-systems/ for a discussion and link to a paper. Here's my implementation: https://github.com/CartwrightLab/MinionRNG/blob/master/minion.hpp#L162-L175 Note: This technique can be modified to produce 32 bit numbers, so don't let the 64-bit algorithm scare you off.

• For even more performance, try replacing the use of MersenneTwister here with a faster RNG. E.g. xorshift* (https://gist.github.com/imneme/9b769cefccac1f2bd728596da3a856dd), xoshiro / xoroshiro (http://prng.di.unimi.it/), or PCG (https://www.pcg-random.org/).

Hope they sort this out. I've built 3 melon and pumpkin farms to keep up with my villagers

This is much closer to parity in 1.19, probably due to the fix to MCPE-145612, but Java stem blocks still produce 10-20% more fruit. I tested identical plots of 16 stems, with each stem having dirt below each adjacent spot and hydrated farmland below each corner-adjacent spot (i.e. max yield layout), for over 3 hours. Java rates were 913 melons, 172 pumpkins/hr, Bedrock rates were 740 melons, 159 pumpkins/hr.

These numbers seem to fit Java having a random tick speed of 3 and Bedrock having a random tick speed of 1 with a hidden internal multiplier of 2.5 (per code digging on MCPE-145612). So Bedrock's effective tick rate is 18% slower than Java's.

These are the worlds with the test plots. Flip the levers on the minecart unloaders up to allow the hopper minecarts to run. Flip the lever on the command block to enable growth and start the timer, and press the button on the other command block to to reset the timer. Note that the Bedrock world keeps time in seconds and the Java world keeps time in ticks.