SwiftUI Performance on Larger Files

[JUSTINMKAUFMAN]

I mostly opened this issue because I stumbled on to this project and wanted to tell you I think it's cool! I actually built a SwiftUI code viewer myself a few months ago, but your project is much more ambitious (with the language-specific syntax highlighting etc.).

Anyways, one thing I noticed when running the demo app and opening even medium-size files (i.e. I tried a ~700 line Swift file) is that the view lags quite a bit when scrolling quickly. I haven't profiled the code or anything, so you'd probably know better than me why it might be sluggish, but one thing that helped me when working on my implementation was to avoid passing editable text as a binding property into SwiftUI views.

So, in CodeEditor, instead of having @Binding var text: String?, you'd have let text: String?. Then you'd add a @State private var editableText: String = "" to CodeEditor and, in the .onAppear of that view, set editableText = text. That way the view maintains its own state when it comes to large chunks of text, which seems to significantly improve performance even on small (1-line) TextField views.

Feel free to ping me on here (or I'm also on Twitter @justinmkaufman) if you ever want to talk shop, and good luck with the project!

[mchakravarty]

Thanks for the report and for the suggestions! You are right, I had noticed the sluggishness myself in some situations, but not actually when scrolling. Did you try a macOS or an iOS build?

In any case, I definitely will have to sit down and do some performance work.

[mlch911]

I have encountered the similar issue. I have a 3000+ line yaml file. It froze the app about 2-3 seconds before its appearance. And it also lags a lot during scroll.

[mchakravarty]

Thanks for the feedback. Which version did you use? The latest "main" branch?

I am asking because I did improve this since the original issue. I am keeping the issue open, because I didn't do proper performance testing, but I am just wondering whether you used the latest main with all the changes I made in the meantime or are you using a tagged (release) version?

[mlch911]

Thanks for the feedback. Which version did you use? The latest "main" branch?

I am asking because I did improve this since the original issue. I am keeping the issue open, because I didn't do proper performance testing, but I am just wondering whether you used the latest main with all the changes I made in the meantime or are you using a tagged (release) version?

I tried the main branch. It will load for 5+ seconds to open. But the lag is much less than before. And another problem is that line number disappears when the line number > 3665. And the line number will wrap to another line when line number is greater than 3 number.

[mchakravarty]

Thanks for that additional information. These are definitely issues that I need to address.

[nkleemann]

Just to bump this, the performance issues persist and make this package unusable for me, sadly. Files over 50 lines of code start to get sluggish - typing, scrolling or navigation with arrow keys all show a delay in response in proportion to the amount of text in the editor.

Otherwise this currently is (at least for me) one of the best options out there for a macOS code editor view for SwiftUI. Solving the performance issue would make it just perfect.

[mchakravarty]

@nkleemann I am actually currently working on improving the performance. I believe that I already know what the main culprit is (the removing and setting of attributes on the NSMutableString underlying the text storage) and I have developed an alternative approach, where I synthesis (token) attributes on the fly.

I am currently testing and benchmarking the new approach. I'll mention it here in this thread, when it is ready for public testing.

[mchakravarty]

@nkleemann Sorry, this took longer than expected as I came across a number of related issues. In any case, performance is a lot better for me now. Please let me know if you still encounter issues.

One caveat is #62, but this is (as the issue explains) really a visual issues (use some placeholder or so) as the time is taken (according to my profiling runs) by the layout algorithm in NSLayoutManager, and there is nothing I can do about that.

[nkleemann]

@mchakravarty Sorry to respond so late. I had the time to test it this morning and performance drastically improved for me. Thank you!

[mlch911]

I test a large json file. It's very smooth now.👏👏👏