Very cool project, but I find it very slow to parse?
Closed this issue · 10 comments
I'm using Mac Studio and it seems to take a long time to parse a project. I just tried RxSwift at first and found it too big so I switched to OpenCombine, but I waited a long time and it was still loading and the LSP server seems to be using only a single core
I'm using Mac Studio and it seems to take a long time to parse a project. I just tried RxSwift at first and found it too big so I switched to OpenCombine, but I waited a long time and it was still loading and the LSP server seems to be using only a single core
Thanks for the input! Retrieving all the codebase data from an LSP server does indeed take long. I haven't optimized performance at all – yet. LSP requests aren't even parallel. So the good news is: There's quite a bit of headroom 😁
Of the planned next updates, the third was actually all about performance. But since Ventura is still a month away, I might as well switch things up and do the performance update 2nd:
- Saving and loading codebase files. This is a Codeface-specific file format turning Codeface into a document-based app. The update will hit the App Store in a few days.
- Optimized performance, in particular of layout updates and LSP requests.
- Migration to new SwiftUI features coming with macOS Ventura, likely allowing animated navigation and other perks
The next update (1) will also help with your issue: A .codebase file stores a whole codebase, including all the data retrieved from an LSP server. Loading a codebase from file is much faster. So when you don't need to update a codebase, you can open it in Codeface without waiting for the LSP server.
Since you mentioned that single core, I thought I might be able to quickly parallelize the LSP requests. So I measured the bottlenecks on a big codebase:
⏱ Retrieving Symbols: 35.13 seconds
⏱ Retrieving Symbol References: 39.81 seconds
But when I had parallelized the requests, I realized that the LSP server communication handler must become thread safe first. So you'll have to wait for update 2 from the list
One caveat though: Unlike usual editors, Codeface needs a whole bunch of LSP requests answered at once. I cannot know or guarantee that LSP servers handle that many concurrent requests correctly or that they're even suitably paralellized to answer parallel requests any faster. We'll have to see.
It would be great if it could be saved as a file, which can save a lot of time. Looking forward to your updates, I really like this project 😃
Update 1 is being reviewed since an hour.
But for update 2, the caveat I suspected seems to be true: Apple's LSP server is not (yet?) able to handle parallel requests faster. And it doesn't handle some parallel requests at all, cancelling queued requests when new ones come in. It's just geared towards traditional code editors. As far as I understand now, parallelization would involve launching multiple instances of the LSP server ... 🤔
Update 1 is being reviewed since an hour.
But for update 2, the caveat I suspected seems to be true: Apple's LSP server is not (yet?) able to handle parallel requests faster. And it doesn't handle some parallel requests at all, cancelling queued requests when new ones come in. It's just geared towards traditional code editors. As far as I understand now, parallelization would involve launching multiple instances of the LSP server ... 🤔
I've run the latest code (not concurrent branching) and the performance is much improved, now it's more of UI problem because when I expand the folder tree the interface gets stuck and the color wheel keeps spinning.
I've run the latest code (not concurrent branching) and the performance is much improved, now it's more of UI problem because when I expand the folder tree the interface gets stuck and the color wheel keeps spinning.
If your perceived performance has already improved, it was probably not a performance- but a (now fixed) UI issue.
Now, the lagging UI is the part of the performance update that relates to layout updates. I'm already on it.
I've run the latest code (not concurrent branching) and the performance is much improved, now it's more of UI problem because when I expand the folder tree the interface gets stuck and the color wheel keeps spinning.
If your perceived performance has already improved, it was probably not a performance- but a (now fixed) UI issue.
Now, the lagging UI is the part of the performance update that relates to layout updates. I'm already on it.
Hey buddy, I ran the latest code again and found that it parses faster, but the UI is still lagging. I looking forward to your continued optimization.
Can you highlight code in code mode? Can you use SourceKit's parsing capabilities to get a close to Xcode-level experience? I've been study on SourceKit recently. I'd like to write a note app that records Swift code, because existing note-taking apps highlight code by regular expression matching. If you have similar ideas, please let me know thanks 😀
Can you highlight code in code mode? Can you use SourceKit's parsing capabilities to get a close to Xcode-level experience?
I still focus on the visualizations that set Codeface apart, so reproducing traditional code editors is not even on the horizon yet. Also, Codeface is actually language agnostic, so I couldn't use SourceKit directly for anything. I want to support all programming languages.
But have a look at CodeEdit. They try to reproduce Xcode, open-source and also language-agnostic.
Version 1.3.1 has been released. It speeds up rendering a lot 😊
I had to sacrifice some consistency in the animation (mostly visible with search), which I'll solve later.
Unfortunately, I don't know how to generally speed up the codebase import itself since LSP requests cannot generally be parallelized, i.e. I cannot assume how different LSP servers would behave.
How's your note taking app coming along? If you care about syntax highlighting just for Swift, I feel there are a lot of ways to do that. You might wanna inquire matt and his projects, in particular SwiftTreeSitter. For language-agnostic solutions, you may want to dig into the CodeEditTextView and also their CodeEdit Discord.
If that answers your questions, I'm gonna close this issue. For future support, come to the Codeface.io Slack Workspace. Codeface is not (yet) intended as open-source. This repo may become private at any point.
Version 1.3.1 has been released. It speeds up rendering a lot 😊
I had to sacrifice some consistency in the animation (mostly visible with search), which I'll solve later.
Unfortunately, I don't know how to generally speed up the codebase import itself since LSP requests cannot generally be parallelized, i.e. I cannot assume how different LSP servers would behave.
How's your note taking app coming along? If you care about syntax highlighting just for Swift, I feel there are a lot of ways to do that. You might wanna inquire matt and his projects, in particular SwiftTreeSitter. For language-agnostic solutions, you may want to dig into the CodeEditTextView and also their CodeEdit Discord.
If that answers your questions, I'm gonna close this issue. For future support, come to the Codeface.io Slack Workspace. Codeface is not (yet) intended as open-source. This repo may become private at any point.
I can feel it, it's a lot faster, but there's a lot of room for optimization, and a slightly larger project switch is a bit slower.
My note-taking App is getting started, and I've made some progress using the SourceKitten library to help me parse Swift code.
Thanks for your follow-up, you can close this issue 😊