Readit Newsmattiemass commented on TextViewBenchmark: A suite of performance tests for macOS text views github.com/ChimeHQ/TextVi... · Posted by u/zdw
Hi!
Can you please give a high-level overview of how the benchmarks work? What are they testing? Scrolling speed? Loading time? Layout change?
These tests are being extracted from an editor project I work on. The tests themselves use the OSSignpost API for high-precision measurements combined with the XCText infrastructure for driving the UI and capturing the measurements. I've been using this combination for performance testing for a while now. It can be flakey a bit, but that's kind of the nature of UI testing sometimes. Still really great when it works.
The only truly interesting test is one that creates a 1 million line document, measures the loading time (extremely fast) and then measures the time it takes to navigate to the final line in the document. This exercises the layout system. It's really fast. On my machine TextKit 1 can do it in about 70 ms, and TextKit 2 in around 10. This isn't quite good enough for 120 fps UI on macOS machines that support it, but it's really close.
Live scrolling and window resize are both things I'm really interested in testing. But, the UI automation framework doesn't, as far as I know, have good ways of driving those interactions. But I may be able to cook something up. Ideas welcome!
mattiemass commented on TextViewBenchmark: A suite of performance tests for macOS text views github.com/ChimeHQ/TextVi... · Posted by u/zdw
Author here. I'm not entirely sure why this project would be of interest, but I noticed it here so figured I'd provide a little more context.
The test suite is small, and there are no concrete results. This is because the very first truly stressful test I got to produced terrible results. Instead of continuing, I began investigating that more closely. I also opened up a developer support ticket (distinct from a Feedback) with Apple. Apple got back to me about 3 day later, pointing out a bug in my use of TextKit 2. I'm a long-time TextKit 1 user, and this stuff is new to me. I also write a lot of bugs.
TextKit 1 is a very fast system. But with this problem addressed, TextKit 2 now outperforms it by quite a bit. From a performance perspective, it seems really good so far.
If you have any other questions, let me know!
mattiemass commented on Chime 2.0 – a Go Editor for macOS chimehq.com/blog/version-... · Posted by u/parsd
I am a paid customer and I've been trying to use it, but it's not useful yet. I bought this as a specialized IDE for Go but then they added Ruby and other languages I don't really care about and Go is not in focus anymore, so, what's the point of being one of the many - Nova, CodeEdit, Sublime Text, VS Code, you name it!
I am disappointed!
I'm truly sorry to hear that you are disappointed. And I really do get it! The full story is long, but I can sum it up with: our number one request, by far, is support for more languages. Even since this release, we've still gotten requests for yet more not yet available.
The hope is that an open source extension system will make it much easier to add new languages and improve support for existing ones.
But, I also want to be really clear: if you aren't happy, contact us and we'll try to make it right. If you are willing, I'd also love to hear from you about problems and/or missing features. We prioritize requests from license holders over all others.
> I think the extension could communication with its containing app, but the system is not set up to do that.
and on iOS, the containing app is likely not running (in a GUI context).
Typically, the extension is its own small program bundled within the app. The app can be run by an end user, while the extension can only be invoked via the extension mechanism.
Same thing on macOS. The containing app does not need to be running for the extensions to be active. You are right that the extension bundle can only be used by this mechanism, but interestingly the containing app can use its own extensions (though this may not make sense in many cases).
I'd like to take this moment to call out how atrocious Apple developer documentation is. This is honestly embarrassing. I would reject contributions at my company that shipped APIs/headers with this caliber of documentation. People who do it regularly get bad performance reviews.
I don't know if it's because they actually hate developers, or they're just bad developers themselves.
---
More on topic, this is an interesting approach to a tricky problem that exploits one of Swift's strengths (a stable ABI) and Apple's tight integration across the system (standardized app installation/structure/store/etc). You expose some functions as an extension/plugin API and other apps can just call them. Neat! IPC kind of sucks!
What could use some more discussion is how if you have two apps running and calling eachother (or being called from eachother), how does that affect the threading model? Are calls scheduled to happen later on the main UI thread, or are they actually coming from a separate process and you need to worry about synchronization if that call affects any kind of state?
The only reason I was able to figure out how to use ExtensionKit at all was because of a chance encounter with an Apple engineer during WWDC that provided some needed information.
I'm sorry to disappoint, but ExtensionKit/Foundation do not make use of any Swift features in the way you describe. It's all just IPC (via XPC), so much of it is useable from ObjC, or even C!
Also, this does not provide a direct app-to-app communication channel. The extensions themselves must be separate executables and run within their own sandbox. I think the extension could communication with its containing app, but the system is not set up to do that. All your scheduling questions are really around how XPC works. The view itself is basically an image within your hosting app, so communication is entirely async to the other process.
Dylibs is for including 3rd party code at build time, maybe a client to consume an API.
ExtensionKit allows you to expose realtime UI or information, coming from an installed app instead of a 3rd party service.
That way you don't have to expose your API or build an SDK. You just have functions in your app that can be invoked.
Also the feature is only provided if the user has that app installed. So the experience is curated.
Practically speaking, that's still basically an SDK. It's all over XPC, but the interface still needs to be defined.
Basically NSOperation scheduled to a non-concurrent operation queue, where the operation itself is made of async calls.
What would be the recommended approach for doing that with swift concurrency ?
https://github.com/mattmassicotte/Queue