8 ms·
Xi creator did an amazing work implementing ropes (https://github.com/google/xi-editor/tree/master/rust/rope https://github.com/google/xi-editor/tree/master/rus
by postit 9y ago
Xi creator did an amazing work implementing ropes (https://github.com/google/xi-editor/tree/master/rust/rope https://github.com/google/xi-editor/tree/master/rust/rope)
The design documents (https://github.com/google/xi-editor/tree/master/doc/rope_science https://github.com/google/xi-editor/tree/master/doc/rope_sci...) explaining the concepts and implementation details is a must for those who want to understand its core.
But I still have my regards regarding input latency being accredited only to the text editor. I recently switched back to Linux (nvim running on alacritty with tmux) and the latency issues magically disapeared. During my iterm2 (and even terminal) period on OSX I felt horrible lag during operations which I don't even have time to blink with my current setup.
The last straw was once I found out iterm2 consuming 10% of my CPU in idle, the issue only happened when any non builtin font (menlo, monaco or courier) was used.
- evanrelf 9y agoHave you tried using Alacritty? https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty
- eeks 9y agoI must concur. With an equivalent vim setup and code files, nothing beats X11/suckless terminal on my OpenBSD machine. Comparing to that, even Alacritty looks like a slug. I must say however that things are looking a bit better in iTerm2 when switching the Metal renderer on. It's just a shame that an Nvidia GPU on OSX is necessary to compete with my $1000 Lenovo with its crappy Intel chip on OpenBSD when it comes to text editing latency.
- tomjakubowski 9y agoHave you tested iTerm2's Metal renderer performance with the integrated Intel GPU?
- eeks 9y agoYes, however matter-of-factly while moving about the office. I did not perceive any difference between the Mac plugged in and on the go.
- Philipp__ 9y agoWow, just gave iTerm2 Nightly with Metal renderer a spin! Holy shiet it's fast and smooth! FINALY! Opened 20k C file in Vim (stock vim 8 that comes with macOS High Sierra), pushed that scroll down and let it roll, it was soooo smooth! Amazing!
- wyclif 9y agoIs there a way to install that with homebrew?
- bhoeting 9y agoI tried it after reading this comment. You weren't kidding. Unfortunately, my Vim isn't rendering properly. About 10 lines in the middle of the screen are blank for some reason. Both in and out of Tmux. Oh well. I'm just happy that I can look forward to Metal rendering being merged into stable.
- willtim 9y agoA more interesting approach would be to use persistent data structures. While possibly slower for some operations, undo is more efficient and there are really interesting opportunities for concurrency. See: https://github.com/arximboldi/ewig/blob/master/README.md https://github.com/arximboldi/ewig/blob/master/README.md
- raphlinus 9y agoI believe xi-rope counts as a persistent data structure. We have plug-ins in separate processes now, for isolation, but might explore having them in-process but in separate threads. The underlying data structure should support that just fine. Is there something I'm missing?
- willtim 9y agoA rope data structure is very almost persistent. So perhaps I am splitting hairs! It could of course be made fully persistent if mutating operations are avoided. This would allow sharing them between threads.
- steveklabnik 9y ago> This would allow sharing them between threads. This is an area where Rust ends up feeling different than many languages: xi's rope uses https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#method.get_mut https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#metho... like this: https://github.com/google/xi-editor/blob/422948d62688dcc2ee09c82b3eae8e433cd8c3ed/rust/rope/src/lib.rs#L653-L684 https://github.com/google/xi-editor/blob/422948d62688dcc2ee0... , which gives you both options. This code uses Rc, not Arc, so it's not currently sharable between threads, but Arc has the same API. Rust cares about sharing more than immutability.
- raphlinus 9y agoNope, it's Arc for exactly that reason, though we're not currently using it across threads right now. The fact that it can support immutable semantics safely is one of the really nice features of Rust.
- XR0CSWV3h3kZWg 9y agoYeah iterm2 is pretty unacceptable. For me alacritty is still missing some polish (i.e. text size keeps on changing when I attached/detach monitors), but it's really solid for using nvim. I've actually been using nvim as my terminal multiplexer instead of using tmux.
- __jal 9y agoiTerm2 with the new renderer is awesome. Even without it on a slow old mac, you can tune it to behave normally. One thing I found in the past was that particular fonts would slow it down a lot - never bothered to hunt down what was going on, but I think the author was/is doing something a little odd there.
- jorvi 9y agoAlacritty is slower than Terminal.app..[1] perhaps placebo effects were/are in play? [1]https://danluu.com/term-latency/ https://danluu.com/term-latency/
- jwilm 9y agoThe article you linked is specifically about latency. There are other factors that contribute to overall terminal experience such as high frame rate and high throughput. Once latency reaches a "good enough" level, it becomes a non issue, and frame rate and throughput remain. Alacritty excels in those areas (there's even a table in that article demonstrating Alacritty's high throughput). There is also a plan[1] for making Alacritty's latency best-in-class. [1]: https://github.com/jwilm/alacritty/issues/673 https://github.com/jwilm/alacritty/issues/673
- squeaky-clean 9y agoI haven't gone through the whole link yet, but the part where they make video game comparisons doesn't make sense. They say > When people measure actual end-to-end latency for games on normal computer setups, they usually find latencies in the 100ms range. And in that very sentence link to a latency test for a game that is notorious for being laggy, and even then it reaches 59.4ms latency. The same video they link, even says (at 1:32) that Overwatch has a button-to-pixel-change latency of about 15 ms! So where is this "usually 100ms" coming from? Just because of this I don't really trust the rest of the article.
- dikaiosune 9y agoThe author of alacritty suggests that there's an IPC performance issue with tmux/nvim on macOS: https://github.com/jwilm/alacritty#faq https://github.com/jwilm/alacritty#faq
- TheAceOfHearts 9y agoHave you tried Terminal.app recently? A lot of people seem to rush immediately to iTerm2... And I used to be one of those, a few years back. But eventually I gave the built-in Terminal.app a serious chance and found it met all my requirements. Although I also stopped customizing my theme, and I keep as many defaults as possible. SF Mono is a great font!
- spinningarrow 9y agoI still can’t get 256 colours working properly in tmux in Terminal.app - any idea if that’s supported?
- MaxBarraclough 9y agoI did the same thing a few years ago. Terminal.app has had tab support for years now. What's the killer feature of iTerm these days? I also recall finding Terminal.app to have lower CPU consumption, matching postit's experience.
- lambdadmitry 9y agoQuake-style console. I'm too addicted to it unfortunately.
- girvo 9y agoLiterally the only reason why I use iTerm 2 over Terminal.app as well. Though I'm tempted to see if I can't replicate a similar "show over anything when a hotkey is pressed" in Terminal.app with some cute AppleScript...
- latexr 9y agoProbably not a big feature for most, but I work with URLs in the terminal a lot and ⌘+click to immediately open them in the browser is convenient. I prefer to open a new Terminal only when I need it instead of keeping one open all day (even if that sometimes happens) and I’ve never noticed an increase in CPU usage that’d made me want to check.