I am very surprised you got those resuls. I haven't tried the code on Windows, but yes, it's a bit bizarre that only the second report looks the same as on my machine. The targeted operating system for this code is Linux so I think I will try it on multiple Linux machines to see wether there's any difference. But Windows should've had the same result really.. :|

1. yes that's true, but please take into consideration that if I'm doing that every time, then when comparing the times of the benchmarks, each of them has this operation inside them, so the order is preserved because I added the operation in each of the scenarios. does this sound like a sane assumption ? I hope it does, but I'm not an expert so maybe I'm wrong

2.

• a) I fully agree, this might be the main cause. However, in the case of assigning a value to a scalar, isn't there some "typechecking" done to see if it's gonna be stored in a SvIV, SvUV,SvPV,SvPVNV. I'm talking about the fact that Perl would need to guess which type exactly the data is, in order to know what kind of data structure it will allocate for it. Whereas if you use unpack, you already tell it what kind of data it's gonna get, so shouldn't that be faster ?
• b) this is done in both access_array and access_packed so it should take about the same amount of time in both
• c)this would just need to do like a memcpy with a given number of bytes from one place to the other, keeping a pointer on the data and just galloping over the data right ? so it shouldn't be so time-consuming

3. c),d),e) so these are not the ones on the LHS of unpack, these are additional ones for the stack ! hmm, any way to avoid that ?