一、緩存機(jī)制

? ? ? ?官方的更新日志中提到宏函數(shù)存在緩存機(jī)制。Slicedlime的快照視頻也有提到這一機(jī)制。翻看源碼得知，緩存的解析后的宏函數(shù)會(huì)存在一個(gè)哈希表里，以傳入?yún)?shù)組成的字符串列表作為鍵。每當(dāng)有宏函數(shù)的參數(shù)集在表中沒有對(duì)應(yīng)的鍵時(shí)，就會(huì)被放進(jìn)這張表里。同時(shí)，表中最多可以緩存8個(gè)解析后的宏函數(shù)。超過上限時(shí)，最先被放進(jìn)表里的函數(shù)會(huì)被先被移除。

二、基本性能測(cè)試

? ? ? ?針對(duì)緩存機(jī)制準(zhǔn)備的測(cè)試函數(shù)：

? ? ? ?另外準(zhǔn)備了一份測(cè)試函數(shù)，用來驗(yàn)證緩存機(jī)制對(duì)性能的優(yōu)化：

? ? ? ?高頻執(zhí)行函數(shù)test:data_default_test（左）、test:data_macro_test（中）、test:data_macro_test_cache（右）的結(jié)果（tps數(shù)據(jù)看上去比較直觀就不放debug日志了）：

? ? ? ?結(jié)論：執(zhí)行不在緩存中的宏函數(shù)、解析宏命令的開銷比對(duì)storage進(jìn)行簡(jiǎn)單的nbt數(shù)據(jù)編輯操作要大，但差得并不是太多，不像nbt操作與記分板操作之間存在幾個(gè)量級(jí)的差距。這個(gè)微妙的差距使得實(shí)際應(yīng)用的過程中，在一些功能實(shí)現(xiàn)上使用宏的新方法與不使用宏的舊方法性能之間的差距非常值得斟酌，如uuid匹配與json文本合并，運(yùn)用宏命令往往只是減少了幾條data命令的使用。

三、具體情形比較

1. json文本合并

? ???之前進(jìn)行json文本合并的方法通常是將兩段json文本存在storage里放在木牌上解析一次拿出合并的結(jié)果，而引入宏命令后只需要一條命令就刻印完成合并工作。測(cè)試函數(shù)：

? ? ? 高頻執(zhí)行函數(shù)generic:text/combine/json_with_format/new_test（左）、generic:text/combine/json_with_format/old_test（右）的結(jié)果:

? ? ??結(jié)論：使用宏函數(shù)的json文本合并性能更好（注：同時(shí)在宏函數(shù)合并的結(jié)果當(dāng)中json文本并未被解析成使用了extra組件的形式）。

2. UUID匹配

? ? ?之前UUID匹配的方法通常是將代查找實(shí)體的UUID存進(jìn)掉落物的Thrower里，再通過on origin改變執(zhí)行者。引入了宏函數(shù)可直接對(duì)傳入的UUID所指的實(shí)體進(jìn)行操作。測(cè)試函數(shù)：

? ? ? 高頻執(zhí)行函數(shù)generic:entity/generic/get_with_uuid/new_test（左）、generic:entity/generic/get_with_uuid/old_test（右）的結(jié)果:

? ? ??結(jié)論：使用宏函數(shù)的uuid搜索稍好性能稍好（注：其實(shí)這里兩種方法輸入的UUID的形式是不同的，不過實(shí)體16進(jìn)制的UUID可以轉(zhuǎn)化外手動(dòng)找個(gè)地方存著，所以在這里開銷忽略不計(jì)）。

? ?? ?歡迎補(bǔ)充更多實(shí)例！