Hi. $$$2e8$$$ operations takes around $$$1$$$ second time in CF (It depends on the power of the judging server), and for calculating memory multiply the size of the arrays you are storing by the size of the type of the array and divide it to $$$1e6$$$ , the resulting number shows you the memory that your program is using.

for example if you have an integer array of size $$$1e7$$$ then $$$->$$$ $$$int$$$ $$$=$$$ $$$4$$$ $$$bytes$$$ $$$->$$$ $$$1e7 * 4$$$ / $$$1e6$$$ = $$$40$$$ $$$->$$$ your program uses around $$$40$$$ $$$MB$$$ of memory.

Or for example you have an $$$integer$$$ array of size $$$1e6$$$ and a $$$long$$$ $$$long$$$ array of size $$$1e6$$$ $$$->$$$

($$$1e6$$$ * $$$4$$$ + $$$1e6$$$ * $$$8$$$) / $$$1e6$$$ $$$=$$$ $$$12$$$ $$$MB$$$.

Hope you understand it.

From what I understand, the Codeforces judging servers run Coffee Lake CPUs clocked at around 3.6GHz. In practice most nontrivial competitive programming solutions are limited by memory latency, so the relevant numbers can be found here.

In practice, playing around a bit on custom invocation with pseudorandom latency-bound accesses on an array that should be firmly in the "almost exclusively L3 cache hits" regime, my observed runtimes are typically about 10-20% slower than that 41 cycles of latency number would suggest. That suggests one typically gets up to around $$$7 \times 10^7$$$ bad memory accesses per second.

Also note that if your working set approaches the size of the L3 cache things get much worse. I suspect the judging of other submissions prevents you from being able to effectively exploit all of the L3 cache, especially during system testing.