Version
22.2.0
Platform
Darwin MBP.local 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
Subsystem
No response
What steps will reproduce the bug?
Profile the following:
import webcrypto from 'tiny-webcrypto';
import encryptor from 'tiny-encryptor';
const SECRET = 'P@ssword!';
const SAMPLE_1GB = new Uint8Array ( 1024 * 1024 * 1024 );
const enc = await encryptor.encrypt ( SAMPLE_1GB, SECRET );
const dec = await encryptor.decrypt ( enc, SECRET );
It should produce a trace like this:
Basically we can see that decryption is way slower than encryption, but how come? There seems to be a useless (arguably) copy of the data buffer when decrypting, but I think it would be totally reasonable to simply delete this copy and getting a subarray instead. It's obvious that you shouldn't be modifying something while its being processed by something else if you don't want problems.
Basically this copy has a tangible cost, obviously, but a very intangible benefit, especially since a "tag" is used, if the underlying buffer gets modified under our nose the decryption should fail, I think.
So basically I think we should switch to a subarray instead of a slice there and get rid of this unnecessary slowness.
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
No slowness caused by operations of dubious utility at best.
What do you see instead?
Slowness caused by operations of dubious utility at best.
Additional information
No response
Version
22.2.0
Platform
Subsystem
No response
What steps will reproduce the bug?
Profile the following:
It should produce a trace like this:
Basically we can see that decryption is way slower than encryption, but how come? There seems to be a useless (arguably) copy of the data buffer when decrypting, but I think it would be totally reasonable to simply delete this copy and getting a subarray instead. It's obvious that you shouldn't be modifying something while its being processed by something else if you don't want problems.
Basically this copy has a tangible cost, obviously, but a very intangible benefit, especially since a "tag" is used, if the underlying buffer gets modified under our nose the decryption should fail, I think.
So basically I think we should switch to a subarray instead of a slice there and get rid of this unnecessary slowness.
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
No slowness caused by operations of dubious utility at best.
What do you see instead?
Slowness caused by operations of dubious utility at best.
Additional information
No response