#67 Functions for unpacking based on byte arrays #71
Conversation
…ed a basic benchmark setup for testing the packer
|
Hi @Uight , |
|
@EFeru i figured that out i was just being stupid ;) |
|
@Uight still need to look into this. I did not forget :) |
| { | ||
| var startBit = signal.StartBit; | ||
| var message = receiveMessage; | ||
|
|
||
| if (!signal.Intel()) | ||
| { | ||
| var tempArray = new byte[message.Length]; | ||
| var tempArray = new uint8_T[message.Length]; | ||
| Array.Copy(message, tempArray, message.Length); |
There was a problem hiding this comment.
This part is bittersweet. It's easy and readable but allocating to just read backward it's a pity.
Maybe if we change the ExtractBits signature into something like
private static uint64_T ExtractBits(uint8_T[] data, int startBit, int endBit, int step = 1) // Or -1 if backward
we could keep the same iteration without assuming that length is the limit. Just food for thoughts.
...or... (this is a bit outside the scope of this PR, but worth mentioning)
Today the Packer is a static class so it needs Signal and message info. If we optimize the Signal class (or if we adda a sort of .GetReader() on it) then we could optimize some stuff, removing ifs, and give a forward/backward reader depending on endianness
This adds some new functions for packing/unpacking can messages based on byte arrays and does also support message lengths != 64 bit.
For me this is considered a base implementation that could be used to build on. (E.g. Message encode/decode function)
I also added a new benchmark project to the solution using dotnetbenchmark. This is optional but could help to tune performance in the future.
resolves #67 (but could be extended in the future to implement message packing aso.)