for line in win.buffer is correct, it fetches the entire buffer once. The problem might be the win.width inside the innermost (line) loop. If you move it out before the loop (width = win.width, as already is done for height), does the difference decrease?

@unphased Vim contains embedded interpter. I.e. it links with libpython and vim.* objects directly call C code. Neovim uses msgpack-rpc so anything like vim.buffer.__getitem__(1) (vim.buffer[1]) is doing “form request -> serialize it in msgpack -> deserialize it on Neovim side -> form the response -> serialize it -> deserialize on the Python side”. Plus the OS doing context switches because Python interpreter is one process and Neovim is another. In Vim this is “convert Python object to Vim -> call some C functions -> convert return value of C functions to Python”, and no necessary context switches. This has nothing to do with compiling/interpreting: libpython is the same both in Vim and Neovim cases. But this is IPC that slows down things which is never going to be just as fast, main optimization strategy here is reducing the number of requests (like suggestion by @bfredl).

Just following up, I think you guys found it. With win.width cached outside the inner loop, performance is very comparable now.

ZyX also wrote a nice answer for my question here which does impact this loop though, I will need to bring it out of python now.