5 ms·
Why are modern text editors so slow? Here's an editor that I use from 1996 opening up a 1GB file of randomly generated bytes (dd if=/dev/urandom of=random_bytes
by biot 10y ago
Why are modern text editors so slow? Here's an editor that I use from 1996 opening up a 1GB file of randomly generated bytes (dd if=/dev/urandom of=random_bytes.txt bs=64M count=16): http://i.imgur.com/BVln6Y2.gif http://i.imgur.com/BVln6Y2.gif -- it opens instantly and I can scrub to any point in the file with no delay. I've yet to find a modern editor that beats my 1996 one.
- humanfromearth 10y agoModern editors are much more that file browsers. They do static analysis, syntax colouring, linting and many more things (depending on what plugins you have installed). I still like to open a plain vim and just focus on the task at hand without the magic, but that's just not how most web developers work these days.
- vidarh 10y agoBut there's not really a good reason why these features can not be processed in the background, e.g. in separate threads. Personally I don't care much about the 1GB file scenario, but I've mentioned before how "booting" AROS (AmigaOS reimplementation) hosted under Linux, straight into an Amiga editor like FrexxEd (which does have syntax highlighting for example) is faster than starting Emacs on my home machine. More importantly, a lot of this functionality is down to simply not thinking about consequences. E.g. try starting a typical Emacs installation on a box that has a network but where the DNS setup is broken, and enjoy waiting for DNS lookups to time out before it starts... (I'm sure there's an easy fix; I'll admit to being lazy and not having looked for how to prevent it and rather "just" fix my DNS when it's happened) All to often "nice to have" functionality ends up in the critical path of startup rather than lazily initialize in the background.