Comment 4 for bug 1707941

Both threads basically block each other here by trying to acquire the interpreter lock (the GIL) all the time.. Waiting for the lock takes time, and handling the GIL itself takes time also. In addition to not giving any benefit at all, the locking/switching/unlocking overhead is so large that it considerably slows down the program execution.

Note that Py3.5 already has better overall GIL locking performance in your example, but it's still large.

When you serialise both parser runs with your explicit lock, the locking overhead during parsing goes away entirely and you end up with the bare single thread parser performance for each of the two runs.