-
Notifications
You must be signed in to change notification settings - Fork 292
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
hash conflict in lyb_hash_siblings #2186
Comments
We were hoping there would not be a module that would exhaust the value space, there was none until now in any case. There are good reasons for using only 8 bit hash, the data size and performance (print/parse) is best. So, my advice is to not use LYB file format if you do not have to. If you do, then you can use your patch but it will not be merged into the repo, it would slow down all use-cases. |
@michalvasko thanks for you reply. but i don't understand why it will slow down use-cases if we use 16bit hash. |
That is fine, very common, and exactly the reason why benchmarks are performed. We measured it during the initial LYB implementation and the results were clear and I believe the reason is exactly that 1 more byte in data for every node. A compile option could be added but a much better solution would be for you to reduce the number of parameters in that one container to 256 max. So, I will not spent any time on such a patch but if you provide it in a PR and is clean enough, I would be willing to merge it. |
hi, @michalvasko i think i submit the merge request #2188 could have a look |
in our case, we have many many parameter in a container, so the hash is exhausted. so we have following error inside lyb_hash_siblings(struct lysc_node *sibling, struct hash_table **ht_p):
the reason is that only 8bit hash in this case.
so we make 8bits to 16bit by the diff here
could you check if it could be merge to the trunk of libyang?
use_16bit_hash.zip
The text was updated successfully, but these errors were encountered: