Thanks for all that. Finally I got the headat approach faster by removing shuffling, removing the range operation (just filling a list with ten million zeroes u

Thanks for all that. Finally I got the headat approach faster by removing shuffling, removing the range operation (just filling a list with ten million zeroes using mylist = [0] * 10000000), and hardcoding the constant for the size of the test as a literal 10000000 rather than a variable (ie headat < 10000000 rather than headat < numtopop). I couldn't remove the initialization code entirely since I'm approximating reading through a list, so in the pop() version, having the list is necessary for being able to do that (otherwise if the initialization is outside the run loop then how do you do the second loop loop after you've already pop()'ed every element). If I reused the same list for each run in the headat version it would be kind of like cheating, since the fundamental reason for this whole exercise is to speed up a monte carlo simulation that depends on shuffling and reading all the elements of a list, which is why I originally included that in the benchmarking code. Anyway even after I removed all that, the headat version is now just 3.2% faster and with everything hard-coded, without any shuffling, the whole thing stops being an approximation of anything actually useful for any real code. So the bottom line is that Python lists are plenty fast and there is no reason to try to do hamfisted optimization with runtime variables, as it doesn't get us any useful speedup.