-
Notifications
You must be signed in to change notification settings - Fork 48
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
Long Spy Generation Time (Both on 11 and 11.1 GM) #29
Comments
Don't think it has anything to do with the target, I'm seeing a couple orders of magnitude time increase too on identical protocols with App Store Xcode 11. Happy to help if there's any useful diagnostics I can perform! |
Hi @joshwoods and @alexcurylo , Thanks for raising this issue. I've been able to reproduce it, but not able to find a solution so far. The problem is that source kit seems to get itself into a weird state. This is what Activity Monitor says: I'm looking into the issue so I'll hopefully get an update out soon. Sorry for the inconvenience! |
I've figured out the issue. SourceKit needs a module cache parameter to find the indexed files now - before this was automatic. You can download the latest update here P.S. If you are interested in getting involved, I'm working on making this 100% open source again to enable people to contribute. I'll post again when that's ready. Enjoy! |
Thanks for the quick update @seanhenry! Unfortunately it hasn't changed the processing time for me. I made sure to check the presence of I've created a brand new project and tried with @joshwoods example, it took 2 minutes. If you have any other ideas, I am happy to try 🙏. |
@waleeg - I've just tried the same and it works just fine for me. I've also tried it on large projects and the performance seems fine. Hopefully we can get this working for you. Could you check the following:
|
@joshwoods does the update work for you? |
@seanhenry I'm also having this issue with XCode Version 11.0 (11A420a).
The generate spy command seems to take an infinite amount of time for me. |
@seanhenry I went through and installed the new update and the path is showing correctly, however, it is giving me the "could not find a protocol". I suspect this maybe has to do with the protocol existing in another target as when I go the manual route (moving the parent folder of the entire project), it works, however, still as slow as before. 🤔
(2 plug-ins) |
Yep
Yep
Mojave 10.14.6 (18G95), Xcode 11.0 (11A420a)
Thanks |
Still seeing it here too after fully cleaning and restarting, stock releases for everything. Mojave 10.14.6 (18G95), Xcode 11.0 (11A420a)
|
I may (or may not) have fixed the issue... I'm not sure why it was working on my machine but I was finally able to reproduce the issue again. I have uploaded a new version but I'm going to hold off from making it an official release until it works for you guys so please do let me know when you've tried it and if it is working or not. If it still isn't working, I've enabled logging of SourceKit requests so if you attach the log we might be able to understand the problem better. To get the log, open the |
Thanks - could you attach the first 10 lines or so of the request - in your case it was written to: Could you also check your |
|
No joy here either and my request looks about the same:
|
Pretty similar on this end:
|
Thanks everyone for your continued testing efforts! I have another build for your to try. I think the problem has been that I've been largely testing on macOS projects and I'm hoping you are all on iOS projects? In the new build you now need to select a platform from the companion app. Try the new build out and if it doesn't work I have some further steps to try:
|
iOS: macOS: I am wondering if the size of the project has anything to do with it... I am working most of my time on a macOS project, it's heavily relying on protocols. Thanks for the support! |
😢 Doesn't seem to make a difference here, but pluginkit still says |
Unfortunately with this new build it still takes about 4 to 5 minutes to generate a spy. Even after following all 6 steps. (Platform: iOS, Xcode 11.0, MacOS 10.14.6) |
@seanhenry Sorry, I've been AFK for a bit on vacation so I haven't been able to respond. I tried pulling down the download you linked to above on dropbox, however, I don't see any option in that build to select a platform so I'm not entirely sure it's correct. But you would be correct, I am building for iOS! |
I have the same problem.
|
I found a workaround. If you copy and paste the protocol on Playground and generate the mock from there, it'll take only 3 seconds. |
@gonzaloalu The performance problem we're having is that SourceKit doesn't seem to be finding the index/cache. So copying the files to the playground works because SourceKit is quick with or without an index when there are only a few files. I'm glad that's working as a workaround for now though. @joshwoods Not sure why the build was incorrect for you but it doesn't seem to work for anyone anyway 😆 I have a new update to try. Just make sure that the companion app is pointing to your project directory - don't worry about the platform selector for this one. |
@seanhenry, seems to be fixed in this build! Generates complex spy's in less than a second. 🎉Thanks! |
@seanhenry so I'm definitely seeing some go a little bit faster than they were. I am sorta thinking that part of my issue now is the way this specific project is setup. For example, I setup a completely brand new project and made a protocol and a mock was created almost instantly. However, using the Also...for what it's worth, I just went and tried to make a mock of this protocol:
It exists in our main target so I wouldn't expect any of the other issues that I indicated above, but it took 2.5 minutes to generate the mock. For what it's worth, from the time that it started, I was monitoring the console for |
@seanhenry 💯 it's fixed and faster than ever! It's instant. Thank you very much. @joshwoods It seems to be project dependent, I just tried your example ( |
@waleeg @TomVanDerSpek That's great news! I'm pleased it's working. @joshwoods I'm pretty sure you're not using the latest version of the app. I have noticed that Xcode can get itself in a weird state and continue to reference old plugins in certain situations. The reason I think this is because there shouldn't be any logs generated in the new build, and it should also fail quite quickly now, even if it can't find your referenced protocol/class. Either that, or there is another unrelated issue to the SourceKit issue. Can you try closing Xcode, deleting the current app, emptying the trash, restarting your machine and then copying the new app into
Unfortunately, it won't find classes or protocols that do not reside in your project directory. There is another open issue for that: #19. I am actively working on this, but it's not a quick fix so I will post again in that issue when it gets resolved. A workaround for this issue is to manually specify the path to your framework project directory in the companion app. It's not ideal, I know, but any source files found in the specified directory should get resolved. You could even arrange your two projects to be side-by-side in the file system and manually specify the parent directory - this would stop you from switching between directories in the companion app. But be careful - identically named protocols or classes are not supported and will result in one being picked at random so be sure not to include other projects in that directory. Thanks for your patience with all these workarounds - 3rd party development tools aren't quite ready to be used in the Apple ecosystem yet! |
well I'll be damned I think you're right! I went through the process of deleting, emptying trash, restarting and reinstalling and we're in business! thank you so much! I even moved the project path all the way to the root (so that it'd include the base target as well as all dependencies) and that seems to work on those ones I was having issues with where it couldn't find the protocol! Thanks so much for all of your work on this!! |
@joshwoods No worries - I'm really pleased it's working for you! |
I've created a new update which adds some other minor improvements to the build that I posted here, so be sure to install the new version ASAP (the version number of the new release is still 0.23). |
We are noticing some long load times on our end when generating spies.
For example:
We have a protocol (listed above), this took ~2 minutes to generate whereas before it was pretty instantaneous.
To be fair,
LocationProviding
is from a different target in our project. I've tried changing out@testable import
and just plain oleimport
of that module in the mock file and neither of those seemed to help. In fact, I think that I had to specifically change the project path to the absolute root path of the project, rather than where the the file actually is (which would encompass both the targetLocationProvider
is in as well as the target the mock is in).Any ideas?
Also...would really love to know if you have any reading material how to get involved with these types of improvements, could totally get some additional eyes on helping keep! :)
The text was updated successfully, but these errors were encountered: