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

Performance of PER codec #244

Open
dudycz opened this issue Apr 10, 2024 · 5 comments
Open

Performance of PER codec #244

dudycz opened this issue Apr 10, 2024 · 5 comments

Comments

@dudycz
Copy link

dudycz commented Apr 10, 2024

Hi. I have been playing with two most popular PER codecs: rasn and asn1-codecs and made some benchmark comparing their performance. One thing I have noticed is that rasn can be ~10x slower in encoding in some complex cases:

Codec Encoding (µs) Decoding (µs)
rasn 1916.7 826.8
asn1-codecs 208 145.5

I looked into flamegraphs and callgrinds but I couldn't figure out what contributes to this big difference. If you're interested I could try to collect some and attach here.

Link to repo with benchmark: https://github.com/dudycz/asn1_codecs_bench

@XAMPPRocky
Copy link
Collaborator

Thank you for your issue! Would you be able to attach the flamegraphs? That would be very helpful. In general the initial version I made prioritised correctness over performance so there's likely a lot of places where it could be more efficient. I already know that I haven't added the empty struct optimisation that was added to BER to PER.

@dudycz
Copy link
Author

dudycz commented Apr 10, 2024

I had to encode sample.asn 256 times to get something recorded in flamegraph. Here it is:
rasn

@Nicceboy
Copy link
Contributor

Nicceboy commented Apr 14, 2024

Seems like your test bench uses mostly integers. asn1-codecs crate seems to use i128 internally for Integer type while rasn uses BigInts. I would guess that this plays big factor at least.

I think there was a plan to make inner implementation of integer types as feature, so that it would be possible to select different internal type for performance reasons if very big numbers are not required.

@XAMPPRocky
Copy link
Collaborator

Yeah, that's still a todo, I should write up an issue giving details in case someone else who has more time is interested.

@Nicceboy
Copy link
Contributor

Yeah, that's still a todo, I should write up an issue giving details in case someone else who has more time is interested.

I think this is rather important optimisation in general and should not take too much work to implement, if we have, for example, just the i128 and BigInts as initial options. If you have time to write what you had on your mind, maybe I can try to do it.

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

No branches or pull requests

3 participants