Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizations in Syntax Highlighting

code.visualstudio.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Optimizations in Syntax Highlighting

#51

Post by kevincox »

dgfgfdagasdfgfa wrote: post #49
trishume wrote: post #27

Earlier quoted context omitted.

Yes it would be possible to write a C wrapper for my Rust library and link that from Node, however I expect you might lose a lot of performance to data conversion. I have yet to do the regex engine port, I'm doing that later this evening. I'm porting it from Oniguruma to https://github.com/google/fancy-regex which accelerates common types of regexes using the awesome Rust regex crate which is super fast.

Doesn't rust export the C abi? Or does the "c wrapper" just involve converting c types to rust domain types>

You can very easily export a C api from rust. And fact you would have to if you wanted to write a wrapper anyways so I think the wrapper is probably unnecessary.

Re: Optimizations in Syntax Highlighting

#52

Post by cel1ne »

nhaehnle wrote: post #23
trishume wrote: post #5

Shameless plug: my implementation of Sublime's syntax highlighting engine in Rust has similar optimizations and more. I'm not at my computer to benchmark on the same files but it should be >2x as fast as their "after" numbers just based on lines/second for JS-like files. This evening I'm even trying to port it to a pure Rust regex engine that should eliminate non-Rust code and make it substantially faster. It also im…

Thanks for this. Clearly the original post describes good work, but I can't help feeling the JS community is slacking off when it comes to performance. Just eyeballing the cited numbers, they take 3939ms to handle a 1.18MB input on "a somewhat powerful desktop machine". Assuming that that means a chip running at 2GHz, we're talking about over 6300 cycles per byte! That's quite frankly ridiculous. An improvement by at…

Reminds me of an "efficient programming" exercise back at university.

We had to implement getuid [0] as an executable in C, which just looks up /etc/passwd by name and returns a number.

By using specialised trie-like data structures and, in the end, also custom memory alignment instead of malloc, we squeezed the whole algorithm runtime down to an average of 45 cycles or so.

[0] http://man7.org/linux/man-pages/man2/getuid.2.html

Re: Optimizations in Syntax Highlighting

#53

Post by trishume »

dgfgfdagasdfgfa wrote: post #49
trishume wrote: post #27

Earlier quoted context omitted.

Yes it would be possible to write a C wrapper for my Rust library and link that from Node, however I expect you might lose a lot of performance to data conversion. I have yet to do the regex engine port, I'm doing that later this evening. I'm porting it from Oniguruma to https://github.com/google/fancy-regex which accelerates common types of regexes using the awesome Rust regex crate which is super fast.

Doesn't rust export the C abi? Or does the "c wrapper" just involve converting c types to rust domain types>

Sorry that's what I meant. Just export c ABI functions in a Rust crate.

Re: Optimizations in Syntax Highlighting

#54

Post by Sean1708 »

trishume wrote: post #32
algorithmsRcool wrote: post #9

Earlier quoted context omitted.

> using the Oniguruma regret engine I'm surprised I've never seen that typo for regex before. It's wonderful.

lol I typed that on an IOS device correctly but it autocompleted it since "regex" isn't a real word apparently.

Well no, it's a portmanteau of "regular" and "expression".

Re: Optimizations in Syntax Highlighting

#55

Post by nerdponx »

zitterbewegung wrote: post #25
iveqy wrote: post #24

So VSCode is great in many ways, and the article might be interesting. But I would never call it fast. It's still really really slow. Just see this comparision: https://www.youtube.com/watch?v=nDRBxtEUOFE

The article only makes the claim that they have made it faster that the previous technique. Most people say VSCode is faster than other electron editors like Atom. I am not sure who has said that VSCode is faster than Vim and it would be safe to assume that Vim would be faster.

Vim syntax highlighting is painfully slow on long lines, which makes it unusable as a Markdown or Tex editor unless you enable automatic explicit line breaking at 80 or 150 characters, instead of letting paragraphs wrap naturally.
Post reply on HN