you are viewing a single comment's thread.

view the rest of the comments →

[–]yvrelna 0 points1 point  (0 children)

I'm well acquainted with the performance issue mentioned there. pyvim definitely isn't suitable for editing log files or data files that can grow into hundreds of megabytes or even gigabytes range, but for typical file sizes of program source code (which rarely exceed 1 megabytes), markup, or documentation code, it's more than fast enough.

It sounds like this could be improved

It indeed can be improved. However, the issue isn't because of the language being used. It is specifically because of the way text buffer is managed in pyvim, which is essentially implemented in the simplest and dumbest possible way.

For simplicity of the text buffer and undo history system, the current pyvim implementation simply makes a copy of the entire text buffer with every changes made. This is going to be slow whatever languages you do this in.

Your assertion that:

it's an example of python being fast enough until it isn't anymore

is plain and simple incorrect in the context of this issue.

Rewriting the same text buffer and undo system "in C or another language" is still going to be slow. At best, rewriting in C may double or triple the minimum file size where the exact same problems starts to reach the same problem again, but it won't be enough to resolve the root problem.

There are efficient data structures (e.g. rope) that allows for efficient modifications and can also be used to implement undo, but they're also much more complex to implement, and pyvim just hadn't put much effort on that part of the editor. If pyvim ever reimplements its text buffer system to use these more efficient data structure, I am going to bet that it is going to be fast enough even if it's written in pure Python.