[kovidgoyal]

Language speed is typically a very small factor in overall speed. Using good data structures and algorithms is much more important.

That's how the new database backend is faster than the old, despite actually being thread safe, which involves overhead for locking. And it's why the editor is so fast. By using various, rather nifty tricks, I was able to make the editor fast. The basic idea is to do as little as possible and that, only when absolutely necessary.

For example, Sigil parses all files when the book is first opened and renames them. There's absolutely no need to do that. Instead, calibre works with html even if it is not strictly valid.

Another trick is that the parsing and fixing of html before displaying in the preview panel happens in a separate process, so it keeps the editor itself feeling responsive, while the heavy works happens on a different CPU core.

Then the checkpoint feature, which is one I am personally very proud of uses hardlinks and copy-on-write so that there is no expensive file copying when creating a checkpoint and minimal use of disk space as well.

The syntax highlighting is both powerful and fairly fast despite incurring the overhead of converting text from Qt's internal representation into python, because I wrote it from scratch, keeping in mind the particular needs and tradeoffs of this editor, rather than using a generic syntax highlighter, which would not have been so optimized.