Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse blocks.json at compile time #330

Open
wants to merge 30 commits into
base: master
Choose a base branch
from

Conversation

user622628252416
Copy link
Contributor

@user622628252416 user622628252416 commented Nov 23, 2024

Description

This pr experiments with parsing blocks.json at compile time instead of packaging the json string into the binary and parsing it at runtime.

If no major downsides to this approach are found, it can in theory be used for other registries as well.

  • Block/State/etc. struct definitions moved to pumpkin-core
  • added pumpkin-data crate to make sure data is only recompiled when absolutely necessary
  • build.rs is used to generate static arrays from json data

Testing

run server, place/destoy/pick blocks

Checklist

Things need to be done before this Pull Request can be merged.

  • Code is well-formatted and adheres to project style guidelines: cargo fmt
  • Code does not produce any clippy warnings cargo clippy

@user622628252416 user622628252416 changed the title Parse blocks.json at compile time Experiment with parsing blocks.json at compile time Nov 23, 2024
@user622628252416
Copy link
Contributor Author

Obervations

  • clippy is configured to skip the macro that generates data, and is therefore not impacted
  • pumpkin-data takes ~30s on my machine the first time it's compiled
  • cargo check appearantly does not share its cache with cargo run and also takes ~30s when checking for the first time
  • incremental compilation is much faster ofc

@user622628252416
Copy link
Contributor Author

user622628252416 commented Nov 23, 2024

new binary size: 11 263 504 Bytes
old binary size: 17 724 240 Bytes
~36 % reduction

both were compiled in release mode

@user622628252416
Copy link
Contributor Author

Soo, what do we think about this?

  1. Is the trade-off of the first compilation taking longer acceptable in the first place?
  2. Should I try to benchmark runtime performance changes? (should be faster, but change might be insignificant) RAM usage should be lower too, but I haven't yet tested that either
  3. Should I do this for the rest of blocks.json (shapes and block entity kinds are still missing) and the other registries (items.json, ...) as well? If a decision in favor of this approach is made I'd be ready to invest the time and do this properly

@user622628252416 user622628252416 marked this pull request as ready for review November 23, 2024 22:33
Copy link
Contributor

@DataM0del DataM0del left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nooooooo!!! 0.00001% increase in compile time!!! bad 100% would not recommend because 0.00001% increase in compileering time

/j

@user622628252416 user622628252416 marked this pull request as draft November 24, 2024 17:07
@user622628252416 user622628252416 marked this pull request as ready for review November 24, 2024 20:06
@user622628252416 user622628252416 changed the title Experiment with parsing blocks.json at compile time Parse blocks.json at compile time Nov 24, 2024
@Snowiiii
Copy link
Owner

I think your are parsing most JSON's way to complex, Take a look at the particles or screens for example. Im sure you could simplify this

 "id": 4,
 "ident": "minecraft:jukebox",
 "name": "jukebox"

to

"minecraft:jukebox": 4

@user622628252416
Copy link
Contributor Author

@Snowiiii I think this is ready, lmk if you have any other concerns

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants