Added link to the official repository

Author: Silicon42

README.md

@@ -2,9 +2,10 @@
 A simple function efficiency tester data pack
 
 Pack Creator: Silicon42
+Official Repo: https://github.com/Silicon42/Function-Benchmark-Pack
 
 This pack is meant to help judge the efficiency of one function (or command) versus another. It does this by attempting to run a number of instances of the function in each tick and seeing how long they took to complete. It is not meant to be a definitive benchmark of your computer and the values that it reports are only meaningfully comparable when under the same conditions on the same computer. Basically it's only useful when you want to know if function A is significantly more or less efficient than function B.
 
 To use this pack, add the pack to your test world's datapack folder and wait for TPI_trend (time per instance trend over the last 5 seconds) to go to 0 and stay around there. Then write down avgNsPerInst (average time in nanoseconds per instance over the last 5 seconds) and/or avgInstances (average number of instances run per tick over the last 5 seconds). This will give you a baseline for how much processing power the pack itself takes. Then edit instanceloop.mcfunction to call your function and repeat for any other functions you want to compare. You can restart the benchmark by calling /function benchmark:reset or /reload. You may also wish to change the tickTarget (target time in milliseconds that the benchmark attempts to fill). This can be done by either editing the appropriate line in init_benchmark.mcfunction or calling /scoreboard players set tickTarget BenchStats <value>. The range must be 0 < tickTarget < 50 and is suggested to be 10 <= tickTarget <= 40. Lower values may be more noisy since less instances are being averaged over and larger values tend to show worse numbers due to recursive loop overhead. If the F3 screen or log shows that ticks are taking longer than 50ms, then you should probably reduce tickTarget as I can't guarantee that the pack will behave well when Minecraft attempts to speed up the following ticks to catch up and may eventually cause the server watchdog to consider Minecraft crashed if the problem is bad enough. Note that since this pack can end up calling many commands recursively in a single tick, it's a good idea to increase the maxCommandChainLength in order to get accurate readings.
 
-Try to run this pack with as few background programs running as possible since the way multitasking works on modern CPUs means that actual cores allocate time for different processes to run and if another process happens to take more time it may take away from the amount of time that the CPU can devote to Minecraft, potentially externally increasing the reading of the time the instances of your function took to run and causing the values to fluctuate more and generally be worse. The world you are running this in should probably also have at least mob spawning and random ticks turned off as well for similar reasons, with as little else occuring if possible.
+Try to run this pack with as few background programs running as possible. This is necessary because of the way that multitasking works on modern CPUs, in that actual cores allocate time for different processes to run and if another process happens to take more time it may take away from the amount of time that the CPU can devote to Minecraft, potentially externally increasing the readout of the time the instances of your function took to run and causing the values to fluctuate more and generally be worse. The world you are running this in should probably also have at least mob spawning and random ticks turned off as well for similar reasons, with as little else occuring if possible.