Tracking issue of known performance issues

[Nicceboy]

OER codec has been optimized fairly well at this point and some optimizations have been carried to other codecs as well.

However, there is some work to do in other codecs and they can take advantage of or note the added improvements during OER optimizations. Most of the possible improvements are related to the reduction of allocations.

BER/CER/DER

• Output construction should always happen to the same output buffer during encoding. If this is not possible (e.g. there is a separate need to encode data before calculating the length is possible, reuse a specific worker buffer)
• Recursive encoder instances should use existing buffers
  • Maybe add encode_buf encoding function at the same time, so caller can pass existing buffer
• rework decode_octet_string method to return always slices instead of vectors and add constraint check at the same time
• object_identifier_as_bytes method should take buffer as parameter and encode into that. This function is also used by other codecs.
• Adding constraint checks potentially improves performance in few situations

UPER/APER

Most of the following optimizations can be mimiced from the OER codec, with slight modifications since its completely octet-aligned.

• Output construction should always happen to the same output buffer during encoding. If this is not possible (e.g. there is a separate need to encode data before calculating the length is possible, reuse a specific worker buffer)
  • If the above is applied, pre-allocations are not needed anymore in encoding - however there are currently some opportunities for that which might reduce the amount of re-allocations
• Recursive encoder instances should use existing buffers. Preamble pre-reservation and relevant overwriting must be added first.
  • Maybe add encode_buf encoding function at the same time, so caller can pass existing buffer
• There are few closure-based patterns to decode data - this makes using borrows challenging e.g. in decode_octet_string method, so it should be re-adjusted
• It is possible to calculate the width of the preamble and store cursor to pointing into that position in the current output buffer (all the needed values are available as constant) - all the data can be then appended to the same buffer as they appear and later the reserved preamble position is rewritten (sample in OER, needs only slight modifications)
• The above applies for extension additions as well - store the cursor at the beginning of the extension additions, calculate the width of the extension bitmap, reserve it and then encode extension additions to the output buffer as they appear, adding length at the same time (open type). Use worker buffer to prevent new allocations when calculating length. (sample in OER, needs only slight modifications)
• In decoder side, there are some pre-allocation opportunities left that can help on avoiding re-allocations
• Presence tracking of optional/extended fields during decoding can use field count constants to make use of static arrays instead of using heap
• Decoding of the extension header should also use the constants with static arrays instead of heap
• Decoding of sequence/set can use field count constants in order to remove some heap allocations
• Decoding anything with open type should get the data as slice instead of heap allocated vector
• decode_length method seems to be very slow - needs some research
• nom_bitvec and BitVec are sometimes very slow - conversions between bitvec/vec and general parsing should be benchmarked if there are improvements available by using different patterns
• There are likely some opportunities left to take better advantage of the constraints for calculating any ranges as the constraints are now almost completely constant

OER

Unsafe improvements (may or may not added?)

• When encoding, using unsafe get_unchecked_mut in optional/extension presence tracking for setting array index, will grant around 5% performance for general logic when extensions and optional fields are present

Errors

Some errors might introduce allocation or other performance penalties if used with format!. Errors likely need some benchmarking too.

[shahn]

There is still a bit of relatively low-hanging fruit in the derive macro. Of course it is much less bang for the buck to optimize there, but still fun :)

Derive Macros

• Do not re-construct tag and tag_tree repeatedly during the same macro invocation
• Reduce clones before token generation