-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[FR] JSON AoS<->SoA redesign #1741
Comments
bold! I agree that the current json is the most naive approach, but before changing it I'd like to understand if it's currently hard for tooling to work with it. I suspect SoA would be easier even without iterations-as-repetitions, but I'd like to be sure. I also agree, one format not two. it's hard enough to lose CSV! if we do change it I think that's a major version bump, no? |
Roundtripping between the two would be trivial for JSON tools, |
Actually, version bump won't exactly help, we don't store version into JSON. It's a classic fatal error... |
oof. maybe we should start doing that first... is that a version bump? :) |
Do we believe that it would it be sufficient just to make it possible |
i think so.. at least then readers have a chance to check it. |
Currently, we emit each repetition separately into JSON (and all at once apparently).
This is quite bloaty.
If we ever want to support iteration-as-repetition thing (and i think we do),
and perhaps if we want to AoS<->SoA our internal structs (and i think we do, especially if we do iteration-as-repetition),
i think we need to change the JSON schema.
The numberic fields (times, counters) need to become arrays of integers.
The
tools/
will support both schemes, but external tooling will need similar updates.I don't think we'd want to support two different json formats?
@dmah42 thoughts?
The text was updated successfully, but these errors were encountered: