Hacker News Reader

Comment by falcolas | Hacker News Reader

I really enjoyed that write up. The only piece I would love to see added would be the addition of emacs and vim in a native console.

View on HN

Yep, I once had just a native console open when installing linux freshly and the lag was so low that I immediately felt how much better it was and that it made me think about lag.

I use terminal based Vim exclusively and now I'm completely spoiled. Every other interface seems ridiculously "laggy". I don't know if it's just a psychological thing or something more like the SpeechJammer, but if I type at a co-workers computer I will sometimes completely lock up and be unable to type for a second or two.

I really don't think that is a psychological thing, i ben using emacs in the terminal for years and only within Apples default Terminal application because iTerm is really laggy on linux i prefer terminology that is really really fast

+1 for terminology. Fast even on the cubieboard that I (also) run it under, and somehow, in my opinion, it does font spacing really well even under Ubuntu. Better than the standard terminal in both Unity and (especially) Gnome where kerning can be weird even on mono font.

No framebuffer, right? In my experience, the framebuffer introduces an annoying and noticeable delay.

I just did quick measurements for vim 7.4 and emacs 23.4.1 in xterm, rxvt/urxvt, and gnome-terminal. The results depend most strongly on the terminal type. emacs' latency is always a bit (0.1-0.3ms or so) lower than vim's. Apart from that, xterm was around 1.1ms, (u)rxvt around 17.5ms, and gnome-terminal around 26.2ms. I wonder where the delay in rxvt compared to xterm comes from.

Depending how you're measuring it, I believe it could be because urxvt's output is buffered by default whereas xterm's isn't. That may mean 16.7ms (= 1 second / 60Hz) is added to the measured latency, though the extra time would have no effect in practice.

ed: or maybe thats excluded from the measurement but urxvt is double buffered by default?

You're right, urxvt refreshes at a maximum of 60Hz (line 1021 in http://cvs.schmorp.de/rxvt-unicode/src/command.C?view=markup). Above, I mistakenly measured only urxvt. Rxvt does a select() with a timeout of 5ms before redrawing (lines 1600 and 1664 in "src/command.c"). The total latency with rxvt is about 5.7ms.

One of the bigger problems with emacs is its font highlighting mechanism - typically it's implemented with regular expressions adding stacked attributes to text. Lexical highlighting using a state machine, with state recorded at line start would be much much faster - like, multiple 1000x faster. Emacs pays for its flexibility with massive performance loss.

Compare something like joe editor (the jmacs named executable has emacs-like key bindings) for syntax highlighting; it's night and day. Joe uses state machines (DFA) in a text description format for syntax highlighting. That means that strictly it can only do lexical highlighting, but that's much much better than nothing - and fully correct syntax highlighting requires a deeper analysis than is normally done in emacs modes.

Joe itself would be much faster again if the state machine was compiled to machine code.

Reply on news.ycombinator.com