In any case, the slowness in comparison with vim was very small, I guess I overestimated it in my previous comment.
I was curious, so I ran an unscientific test. This is resource utilization as reported by top.
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND
1152 ~~~~~~~+ 20 0 146.9m 77.0m 0.0 0.5 0:00.57 S `- kak file0.csv
1319 ~~~~~~~+ 20 0 165.0m 94.4m 0.0 0.6 0:00.23 S `- nvim file0.csv
1333 ~~~~~~~+ 20 0 249.5m 79.2m 0.0 0.5 0:00.18 S `- vim file0.csv
1355 ~~~~~~~+ 20 0 90.3m 5.3m 0.0 0.0 0:00.01 S `- vis file0.csv
file0.csv is a 58MiB csv file I made to test large file handling in another application. Each line is at least 10k characters.To push the limits, I tried to convert commas to spaces with a naive global search and replace. There are approximately 4 million commas in this file. Kak totally chokes on "%s,". Both nvim and vim do fine. Vis not only chokes but consumes a huge amount of memory and needs to be killed with -9.
I run Arch, so I have old-fashioned vi available as well. Vi cannot open files this big.
I did build kak in debug mode (but that was only because I had problems I was trying to debug and get help with on the kak IRC), so maybe I'll blame that and try kakoune again some time.
I wouldn't say that -- the way vis does regex is pretty neat. I'd say all the editors have limitations. Vim is super efficient for global search and replace because after all these years it's still ex underneath, and ex is good at that kind of thing. Vis and kak choke on my ridiculous global search and replace test because they both want to create four million cursors at once. But on the other hand, vis needs the least memory if all you're doing is opening the file, and it seems pretty snappy for ordinary editing tasks. I'm sticking with kak because I'm addicted to selection-oriented editing.
Large as in massive tho, several hundred MB. Not my source code files, thankfully.