The memory access cost is part of the cost of arithmetic -- the operands and results need to be read from and written to memory. It is not explicitly counted b

The memory access cost is part of the cost of arithmetic -- the operands and results need to be read from and written to memory. It is not explicitly counted because the precise sequence of events is very architecture-specific (in a register machine, there will be load/store operations; in a three-address architecture, memory is explicitly accessed by each opcode; in a stack machine, operands need to be pushed onto the stack; etc.), but in any RAM machine the cost of memory access is constant (i.e., it is upper bounded by a constant -- it may be faster if you already have the data in a register or a cache, but the worst case does not depend on the input size or algorithm being run). As for problem sizes not growing, I think your view is a bit limited. For example, matrices in a financial model might become larger if any number of parameters change -- the time period, the number of instruments, etc. Sure, there are cases where you can guarantee that the problem size will not change -- but one of the big advantages of software is that it can scale arbitrarily (unlike a matrix multiplier circuit).