the extension language, I'm guessing.

The second half of that line seemed to be alluding to something else. I'm not saying it's fast, but I've never encountered it's speed being a problem in practice.

The effect can be seen in the highlighter sometimes. If there are too many rules to parse the file correctly, sometimes it will parse just a few lines before the screen. This can randomly result in the first line being highlighted like it's a part of some string. And the whole highlighter/parser is a really bizarre world of regexes and almost-tokens.

I just noticed that if I use too many plugins (where too many in my vimrc is > 12) the startup time can be a bit slow (3-4 seconds).

Compare it with emacs in which I have far more plugins and it still starts fast as a clean install.

Anyway not a big problem eh. For me vimscript is the shitty part of vim.

I just want to say that it's likely not the amount of plugins it's the weight each have, likely you have a few heavy ones causing your boot to be slow. I use ~20 plugins and startup time is still under a second when opening a 35000 line file, try using --startuptime

That sounds like an issue with specific plugins not loading on demand. Though it's not always avoidable, like when you open vim with specific files which triggers the lazy loading.

i've only flirted with vim, but my experience is that while it was admirably fast on medium and small files, it fell over completely on large files or even normal-sized files with long lines.

This must of been a plugin (code highlighter or something). Vim should have zero trouble with big files.