-
Notifications
You must be signed in to change notification settings - Fork 382
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
Evaluate dumping .lib.json without indentantion #315
base: main
Are you sure you want to change the base?
Conversation
@umarcor thanks for testing the lower bound.
|
If it is not going to be human readable, might as well just use compressed JSON files which is much higher than 60% (I think like 95%!). FYI - A good option is to do a blobless clone - https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ |
I think the content should not be "easily" human redable, but it should neither be compressed JSON. If it was compressed JSON, I would suggest using some more efficient binary format instead. The point of having it compact but plain JSON is that any user can quickly reformat it. Just opening it in any online JSON linter will provide a nice indented view (e.g. https://codebeautify.org/jsonviewer). Something such as https://drom.io/inspect might be added to the skywater site for supporting either browsing a list or drag&drop. On the other hand, git does not like single long lines at all. Therefore, we might want to use multiple lines, indeed, for avoiding each change forcing all the file to be recorded. Otherwise, the repo will grow larger than it would without "optimisation". @drom, were the rules you proposed meant to handle this?
I think we are talking about the size of the JSON files in a currently ready-to-use (cloned) dir. That is, we are not considering the size of |
I am for preserving "human readable" JSON format.
https://gist.github.com/drom/86facb54fe0875b0e63bb7598df06310 example: ...
"pin,Y": {
"direction": "output",
"function": "(!A1&!B1&!C1&!D1) | (!A2&!B1&!C1&!D1)",
"internal_power": [
{
"fall_power,pwr_template13x7": {
"index_1": [0.01, 0.01735, 0.02602, 0.03903, 0.05855, 0.08782, 0.13172, 0.19757, 0.29634, 0.44449, 0.6667, 1, 1.5],
"index_2": [0, 0.00636, 0.01271, 0.02542, 0.05085, 0.10171, 0.20341],
"values": [
[0.04431, 0.03219, 0.02014, -0.00392, -0.05218, -0.14876, -0.34199],
[0.04497, 0.03287, 0.0208, -0.00333, -0.05158, -0.14815, -0.34152],
[0.04544, 0.03328, 0.02133, -0.00287, -0.05105, -0.14762, -0.34084],
[0.04606, 0.03386, 0.02186, -0.00226, -0.05057, -0.14719, -0.3404],
[0.04631, 0.03422, 0.02224, -0.00183, -0.05012, -0.1467, -0.33993],
[0.0461, 0.03421, 0.02226, -0.00177, -0.0499, -0.14643, -0.33957],
... |
yes, @umarcor I was thinking about Web UI for browsing / searching libraries, and rendering selected cells online. |
This is a draft for showing some CI results. NOT TO BE MERGED.
In this PR, a workflow and a Python script are added. The script searches all
*.lib.json
files inlibraries/*/latest
and_dump.write_text(dumps(loads(item.read_bytes())))
. Results show that the size can be reduced to ~39%:/cc @mithro @drom