Suponiendo una arquitectura de 32 bits, el memcpy se reduce a una sola instrucción mov (o similar). Entonces es más rápido. Pero también está mal. Desde el punto de vista de C, está invocando un comportamiento definido por la implementación al hacer eso. Lo que podría suceder en realidad es que sus bytes estén ordenados incorrectamente, dependiendo de si está en una plataforma big endian o little endian . Entonces, solo use la solución de cambio de bits en lugar de preocuparse por el rendimiento.

El memcpy en C generalmente se garantiza en los compiladores modernos para optimizar y ser la forma más rápida de copiar disponible. Sin embargo, esto supone que está correctamente integrado en su implementación.

Tampoco creo que esto provoque violaciones de alias estrictas ya que los dos punteros nunca tienen alias en la misma memoria.

Sin embargo, el orden en que se copian los bytes de int en qué byte de la matriz está definido por la implementación. Si quisiera asegurarse de que esto siempre estaría en el orden big endian, primero podría ejecutar htonl en el int, lo que lo convertiría en big endian, luego los resultados de la copia estarían bien definidos. Esto también se optimizaría a nada en caso de que no fuera necesario, lo que la convierte en la implementación más rápida en cualquier sistema.

Si, por otro lado, desea un ordenamiento de bytes Little Endian, use htole32 para asegurarse de que el int se convierta en Little Endian en cualquier hardware. Sin embargo, tenga en cuenta que htole32 es una extensión en BSD, Linux y varios otros sistemas operativos y no se garantiza que esté disponible en todas las implementaciones (lectura, no estándar).

Creo que memcpy será más rápido, porque no calcula solo usa el movimiento. el cambio de byte tiene cálculo de paso de remolque.