Thankyou for your questions. They made me go back and re-test Saving vectors between runs and comparing their contents, changes things -- to the much more bel

Thankyou for your questions. They made me go back and re-test Saving vectors between runs and comparing their contents, changes things -- to the much more believable result of aArray being slower Only comparing the array lengths, but not their contents probably let gcc optimize out assignmemnts for aArray, but not std::vector -- leading to an unfair test Interestingly yes, std::vector now wins by a larger margin for int8_t arrays, and int64_t becomes a tighter match ----- Note: I've updated the website to remove the 1/3 claim! But I can no-longer edit the title of this thread The remaining stool legs of aArray are safety, simplicity, and being generic -- hopefully they don't get kicked out from under it quite so quickly ;^)