The current spec says, in most of its methods, some variant of:

2. Let data be the result of getting a copy of the bytes held by the data parameter

3. Let normalizedAlgorithm be the result of normalizing an algorithm, with alg set to the algorithm parameter

which in turn ends up accessing properties of algorithm, which might have getters (which might mutate the data). So, we need to copy the data before doing anything else, which may be inefficient, especially if we want to add a synchronous version of the API (#167).

So, we may want to swap these operations, if that turns out to be web-compatible.

This issue was split out from #167 (comment) and following comments:

The JS object parameters must account for custom getters (which might mutate everything), which means the exact order that parameters are accessed must be specified. As specified, the input buffers are copied before reading the getters, which is another forced copy.

(...) by changing the order of operations. I strongly doubt that any user of the API is modifying the input data in algorithm object getters.

I would also be surprised if anything but (I hope!) WPT is sensitive to this. Though resolving the algorithm first means we tolerate arbitrary modifications to the buffers before we do the operation. I don't know if it's possible for those buffers to somehow stop being buffers or do something extra weird in between the two, such that some check by the IDL layer becomes invalidated.

(I actually don't know. I'm not an expert on JS state and the assumptions made by IDL layers. Probably need to talk to an expert there. What happens if the algorithm object has a custom property that, on access, transfers the underlying buffer to a message port. Does that put the object in some kind of bad state? Or if it messes with the prototype?)