-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misc clap needs #82
Comments
I'm not sure how much details you actually need to figure out about the escape sequences, or if you're just looking to discard them, but to me it sounds like there's more things that your usecase doesn't share with Ultimately if you take out the char-by-char parsing, remove the performance, then throw out some of the escape sequences you don't care about, there's not much of an escape sequence parser left. If you think you can make things work without affecting VTE's performance, I'd be happy to help adapting it to your usecase. But it sounds like that might not be the best approach depending on what your actual application is. That said, it might not make much sense to rewrite VTE entirely unless the char-by-char parsing performance and binary size actually make a difference, so I'd probably try and measure that first. |
For build times, my initial changes to I'm actually surprised that switching away from the table didn't change binary size, so that could possibly be reintroduced with self modifying code. I'll have to get further into my experiment to be able to say whether runtime performance is improved for my application. I'm actually considering this as a wrapper around |
Dropping utf8parse saved around 40ms of build time. Its not much but my design will unlikely unuse it so cutting it would be helpful. |
Would you be open to upstreaming parts of my experiment like:
Holding off on suggesting any more as I need to see how the ideas pan out |
In my experience doing benchmarks with criterion has been extremely unreliable. I doubt this would actually provide any real-world benefit.
I'd highly discourage any imports like this in Rust code, but I suppose I'd be open to the idea of changing it.
You mean code generation that has to be done manually? That seems extremely inconvenient for development and its benefits seem questionable to me. |
In #4, I researched different libs I could use for this but none fit the bill. I approached `vte` about making changes to fit our needs but it didn't seem like there was interest (alacritty/vte#82), so instead we are using it as the base for what we need.
In #4, I researched different libs I could use for this but none fit the bill. I approached `vte` about making changes to fit our needs but it didn't seem like there was interest (alacritty/vte#82), so instead we are using it as the base for what we need.
Oh, I agree about avoiding
I've found for low-churn code-gen, it offers big compile time improvements and using some snapshotting library with it makes it easy to enforce / update. I've switched all of my codegen from Thought I'd post an update now that I also have runtime performance numbers. Key:
|
For clap and related applications, I've been looking into ANSI parsers. None quite meet my needs so I was looking at writing my own (or forking vte and turning it into what I want) but I figured I'd reach out first in case there is a way to make this work within vte and its of interest.
vte seems like it is optimized for developers for use in alacritty. Performance would most be noticed in highly interactive applications which would have a high escape code to text ratio. Since every control code needs to be processed to render correctly for alacritty, vte cares more about the control code side of printable control codes like
\n
. As the build times and binary size are likely a drop in bucket for alacritty, I'm assuming they haven't been optimized.My care abouts are the opposite of the above. My applications are static and likely to have a low escape code to text ratio and I would want to treat all printable control codes as text. Technically, this can all be handled with vte's design but the char-by-char processing won't be the most optimal. Instead I'd want to deal with slices of text.
clap
is also a heavily used crate and there is a lot of interest in managing the build times and compile sizes. I could likely get away without the proc macro generated state tables and replace them with a function with matches and have little performance hit but massive compile time and binary size improvements.What I'm trying to decide is how much to contribute
vte
to handle both cases or if its better to go my own route. Thoughts?(sorry, wasn't there if there was a better medium to reach out)
The text was updated successfully, but these errors were encountered: