5 ms·

> On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game

by Ygg2 4y ago

> On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) Yeah. Just update a tiny rectangle. And check Unicode validity. And render the Unicode character And re-do highlight. And spawn a box with autocomplete. Or not. And run the AST analysis. And depending on language check if there is an extension dealing with it. List goes on. I dislike the simplification that the article glosses over. Games are fast because they do one or few things that GPUs are great at. Text editors aren't as fast because they do a bunch of things that aren't as easily ported to a GPU.

anonymoushn 4y ago
Unicode validation runs at gigabytes per second. Text rendering is a tiny, tiny subset of game rendering. Not sure about highlighting, sounds like a mix of parsing and game rendering, so that's likely again to be one process that can run at gigabytes per second and another process that is a tiny subset of a process that often runs at 240Hz these days. Autocomplete, no clue, probably this could also be fast? You're like doing a lookup into an inverted index or a hash table or a range tree or something? So it takes like less than 3 microseconds to decide what the contents of the box should be? Oh, it doesn't, because you decided the way this should work is that several different processes should communicate with each other using JSON-RPC just to figure out what goes in the autocomplete box? Yeah, okay, sounds like a problem with the design then. Notably World of Warcraft does not send json over sockets between multiple local processes to decide how wide the nonempty part of each mob's health bar should be every single frame, and maybe one day we could try to figure out whether there's a reason for that.
- Ygg2 4y ago
  >Code validation runs at gigabytes per second. You sure about that? I remember UTF8 validation being a major source of slowdown when parsing XML in Rust. Branches kill CPU perf. And UTF8 has branch on every non ASCII char. Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. Even text editors that forgo LSP have speed issues, unrelated to JSON.
  - anonymoushn 4y ago
    > Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. I've been writing this sort of parser lately and I don't think people's fear of this stuff is at all proportional to the actual level of difficulty. Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0]. If you didn't use an off-the-shelf implementation, you would need 2 implementations of your inner loops to you target ~all x86 machines + M1 macs or 3 if want to go slightly faster on the vast majority of x86 machines that have AVX2 without dropping support for those x86 machines that have a bunch of SSE extensions but not AVX2. > Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. I'm arguing that IPC is suboptimal for use cases that do not need IPC. > Even text editors that forgo LSP have speed issues, unrelated to JSON. I'm arguing that this is probably not due to the essential complexity of text editors. As an unrelated toy example of the sort of thing that I'm talking about, recently I'm playing a game in which people implement somewhat fast wordcounts[1]. The reference solution uses std::iostream to put space-delimited strings into a std::unordered_map, then gets them all out into a std::vector and std::sorts them. This implementation works at about 33MB/s for large inputs. It's generally a lot more efficient than the sort of code you'd commonly find in a larger code base just because libstdc++ isn't as slow lots of other things and it uses vaguely correct data structures and algorithms. It seems like someone who never looks at any assembly listings and never uses a profiler but sort of has some vague idea of what data oriented design is could easily come up with a solution that processes large inputs at 200MB/s even if they are paying some minor overhead for the JVM, the CLR, the Go runtime, or something like that. [0]: https://github.com/cyb70289/utf8 https://github.com/cyb70289/utf8 [1]: https://easyperf.net/blog/2022/05/28/Performance-analysis-and-tuning-contest-6 https://easyperf.net/blog/2022/05/28/Performance-analysis-an...
    - Ygg2 4y ago
      > Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0] Problems with that: - You still need a fallback and to deal with different archs. - SIMD is a different way of coding. You can't take algorithm from Wikipedia and just implement it in SIMD. - Even if you code it to perfectly use SIMD, using those instructions, might result in higher CPU demands. - You will still lag behind games, because those use CPU+GPU while this heavily taxes CPU. You would need some GPGPU. Which is like SIMD all over again. > I'm arguing that this is probably not due to the essential complexity of text editors. Today's code editors are less text editors and more databases of ASTs. They very much are complex by necessity.

by Ygg2 4y ago

anonymoushn 4y ago

Unicode validation runs at gigabytes per second. Text rendering is a tiny, tiny subset of game rendering. Not sure about highlighting, sounds like a mix of parsing and game rendering, so that's likely again to be one process that can run at gigabytes per second and another process that is a tiny subset of a process that often runs at 240Hz these days. Autocomplete, no clue, probably this could also be fast? You're like doing a lookup into an inverted index or a hash table or a range tree or something? So it takes like less than 3 microseconds to decide what the contents of the box should be? Oh, it doesn't, because you decided the way this should work is that several different processes should communicate with each other using JSON-RPC just to figure out what goes in the autocomplete box? Yeah, okay, sounds like a problem with the design then. Notably World of Warcraft does not send json over sockets between multiple local processes to decide how wide the nonempty part of each mob's health bar should be every single frame, and maybe one day we could try to figure out whether there's a reason for that.

Ygg2 4y ago
>Code validation runs at gigabytes per second. You sure about that? I remember UTF8 validation being a major source of slowdown when parsing XML in Rust. Branches kill CPU perf. And UTF8 has branch on every non ASCII char. Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. Even text editors that forgo LSP have speed issues, unrelated to JSON.
- anonymoushn 4y ago
  > Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. I've been writing this sort of parser lately and I don't think people's fear of this stuff is at all proportional to the actual level of difficulty. Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0]. If you didn't use an off-the-shelf implementation, you would need 2 implementations of your inner loops to you target ~all x86 machines + M1 macs or 3 if want to go slightly faster on the vast majority of x86 machines that have AVX2 without dropping support for those x86 machines that have a bunch of SSE extensions but not AVX2. > Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. I'm arguing that IPC is suboptimal for use cases that do not need IPC. > Even text editors that forgo LSP have speed issues, unrelated to JSON. I'm arguing that this is probably not due to the essential complexity of text editors. As an unrelated toy example of the sort of thing that I'm talking about, recently I'm playing a game in which people implement somewhat fast wordcounts[1]. The reference solution uses std::iostream to put space-delimited strings into a std::unordered_map, then gets them all out into a std::vector and std::sorts them. This implementation works at about 33MB/s for large inputs. It's generally a lot more efficient than the sort of code you'd commonly find in a larger code base just because libstdc++ isn't as slow lots of other things and it uses vaguely correct data structures and algorithms. It seems like someone who never looks at any assembly listings and never uses a profiler but sort of has some vague idea of what data oriented design is could easily come up with a solution that processes large inputs at 200MB/s even if they are paying some minor overhead for the JVM, the CLR, the Go runtime, or something like that. [0]: https://github.com/cyb70289/utf8 https://github.com/cyb70289/utf8 [1]: https://easyperf.net/blog/2022/05/28/Performance-analysis-and-tuning-contest-6 https://easyperf.net/blog/2022/05/28/Performance-analysis-an...
  - Ygg2 4y ago
    > Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0] Problems with that: - You still need a fallback and to deal with different archs. - SIMD is a different way of coding. You can't take algorithm from Wikipedia and just implement it in SIMD. - Even if you code it to perfectly use SIMD, using those instructions, might result in higher CPU demands. - You will still lag behind games, because those use CPU+GPU while this heavily taxes CPU. You would need some GPGPU. Which is like SIMD all over again. > I'm arguing that this is probably not due to the essential complexity of text editors. Today's code editors are less text editors and more databases of ASTs. They very much are complex by necessity.