TLE on standard input/output

The first time I implemented a segmented tree, I got a TLE.

Below is a formatted version of the profile results. The numbers are the number of executions, total execution time, execution time per execution (usec), and percentage of the total.

code::

200000 2601965.0 13.0 15.5

No, no, no, you're spending 15% of your time on one line of data loading!

What's the code for AC people?

code::

200000 374839.0 1.9 1.3

c, d = map(int, input().split())

What? Is it so different if it's a MAP or a closed list package?

I'll rewrite mine on map.

code::

200000 2244127.0 11.2 14.2

C, D = map(int, input().split())

Mine is 11.2 usec and the AC guy's is 1.9 usec, even though they are the exact same code, what does that mean?

Compare the output part as it pings here.

I used to print every time in a loop, AC's were compiled in a list and printed after the loop was over.

I'll try to copy and modify it. It's not getting faster just for this output part. In fact, it has slowed down slightly.

code::

before

200000 383636.0 1.9 2.4

after

200000 222367.0 1.1 1.4

1 176312.0 176312.0 1.1

print(*answers, sep="\n")

And as a result of this modification, the input portion was nearly doubled from 11.2 usec to 5.7 usec.

code::

200000 1135919.0 5.7 7.0

C, D = map(int, input().split())

Now my TLE'd code is AC. Seriously....

This is still more than twice as slow as the 1.9 of the AC people. I wonder what else is affecting this... Mystery...

Ah, mystery solved.

code:python

import sys

input = sys.stdin.buffer.readline

Surprisingly, the difference is more than 10 times. In competition programming, where the execution time limit is often 2 sec and the number of input data is 106, a difference of 0.3~0.4 sec is quite significant.

code::

200000 311399.0 1.6 10.9

C, D = map(int, input().split())

and they all lived happily ever after (traditional ending to stories)

memo

sys.stdin.buffer.readline reads as a sequence of bytes

line break at the end of a line

---