Running opgpcard status and gpg --card-status is pretty slow compared to other implementations. This is likely why #144 only affects us.
Supposition:
TLV
TLV serialization often doesn't make assumption about the size of the inner data, so the data in the buffer ends up being moved around (see Reply::prepend_len)
Interchange syscall overhead
Data outside and inside the interchange is copied around all the time. It's first constructed on the stack, then it's copied into the interchange. When it's read, the opposite happens, it's copied on the stack.
The solution would likely be to use references. We can build the data in place with Requester::with_request_mut and Responder::with_response_mut. We can also avoid unnecessary copies by reading the response by using a reference rather than copying it on the stack.
apdu_dispatch, usbd-ccid overhead
Currently there are multiple places where data is buffered and placed into interchanges. Ideally the use of interchanges should be minimal.
Running
opgpcard statusandgpg --card-statusis pretty slow compared to other implementations. This is likely why #144 only affects us.Supposition:
TLV
TLV serialization often doesn't make assumption about the size of the inner data, so the data in the buffer ends up being moved around (see Reply::prepend_len)
Interchange syscall overhead
Data outside and inside the interchange is copied around all the time. It's first constructed on the stack, then it's copied into the interchange. When it's read, the opposite happens, it's copied on the stack. The solution would likely be to use references. We can build the data in place with
Requester::with_request_mutandResponder::with_response_mut. We can also avoid unnecessary copies by reading the response by using a reference rather than copying it on the stack.apdu_dispatch, usbd-ccid overhead
Currently there are multiple places where data is buffered and placed into interchanges. Ideally the use of interchanges should be minimal.