ehrumsey/isuckatcode-pages
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2025-03-25 10:28:04
All checks were successful
Update pages on webserver / Update (push) Successful in 6s
Details

Browse Source
This commit is contained in:
themodernhakr 2025-03-25 10:28:04 -05:00
parent 83bb4b114d
commit d4d0488b91
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Minecraft Datapacking/When Two Macros are Faster than One.md
View File

@ -2,7 +2,7 @@
title: when two macros are faster than one
draft: "false"
---
While working on my Database datapack (still WIP), I knew I'd want to find the most efficient way to dynamically access dynamically populated arrays. I had some ideas and decided to benchmark them using [Kragast's Benchmark Datapack](https://www.planetminecraft.com/data-pack/benchmark-6443027/). This process was really illuminating to me, and I hope it will be for you as well. Thanks for all the help from **PukiSilver**, **amandin**, and **Nicoder**.
While working on my Database datapack (still WIP), I knew I'd want to find the most efficient way to dynamically access dynamically populated arrays. I had some ideas and decided to benchmark them using [Kragast's Benchmark Datapack](https://www.planetminecraft.com/data-pack/benchmark-6443027/). This process was really illuminating to me, and I hope it will be for you as well. Thanks for all the help from **PuckiSilver**, **amandin**, and **Nicoder**.
# scenario
## dataset
@ -73,16 +73,16 @@ data remove storage test_namespace:test_namespace temp.keyword
data remove storage test_namespace:test_namespace temp.result
```
# two macro
Another way to crack the problem is through indexing. This was my original plan when I didn't realize that `...[string:$(keyword)]` was possible.
Another way to crack the problem is through indexing. This was my original plan when I didn't realize that `...[{string:$(keyword)}]` was possible.
This method requires the creation of an index of the field that is going to be searched. The index will look something like this:
```json
[
{entry1: 0},
{entry2: 1},
{
entry1: 0,
entry2: 1,
...
{entry500: 499}
]
entry500: 499
}
```
The *key*, e.g. `entry2:` corresponds with the value of a `string` field in the main array, while the value `1` indicates the main array index where we'll find the full entry. The index can be searched with a direct path, `index.$(keyword)`, and the main array can also be searched with a direct reference to the entry index, `array.#(index)`. Keep in mind that *the index must already exist prior to running the search function*. In a practical application, an index could be updated every time the main array is updated. A scheduled task could also audit the index to ensure that it's up to date.
@ -115,7 +115,7 @@ data remove storage test_namespace:test_namespace temp.index
data remove storage test_namespace:test_namespace temp.result
```
# two is faster than one??
I ran benchmarks on a simple iteration-based function and the single-macro function suggested by **PukiSilver** and **amandin**. I also threw in the two-macro indexing function since I had already coded it. I assumed using one macro would be faster than two, but I was curious exactly *how* much faster it would be.
I ran benchmarks on a simple iteration-based function and the single-macro function suggested by **PuckiSilver** and **amandin**. I also threw in the two-macro indexing function since I had already coded it. I assumed using one macro would be faster than two, but I was curious exactly *how* much faster it would be.
As expected, the iteration-based function was sloooooow. Both macro functions blew it out of the water. Unexpectedly, however, the `two_macro` function doubled the performance of the `one_macro` function. Here are the results (bigger is better):