Is it just me or Xcode 6 (6.0.1) with Swift seems to be super slow when you type your code, especially with autocompletion?
A normal Objective-C class, even if inside a Swift project, works almost the same as before, so it's Swift that kills it.
Does anyone else experience the same inconvenience? Do you have any idea of how to improve performance?
I tried to play with some settings but no luck.
I've also of course tried restarting Xcode and the computer with no luck.
No other heavy
apps are open.
I use a Mid 2009 Macbook Pro (2.26 GHz Intel Core 2 Duo) with 8GB RAM and SSD HD, which is not the newest thing at all, but still not a complete junk.
It is a shame as I was excited to start using Swift and it is now really unbearable.
Thoughts / tips?
Quit Xcode and restart the Mac are not required but preferred.
Delete the content of the folder
~/Library/Developer/Xcode/DerivedData
Delete the content ~/Library/Caches/com.apple.dt.Xcode
This is a temporally solution, but works greatly.
Below the script using Script Editor app.
tell application "Terminal"
do script "rm -frd ~/Library/Developer/Xcode/DerivedData/*"
do script "rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
end tell
Alternatively, you can create an alias for your terminal like this:
alias xcodeclean="rm -frd ~/Library/Developer/Xcode/DerivedData/* && rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
You can add that to your ~/.bash_profile and then type xcodeclean on the command line every time you would like to clear those two folders.
I also experienced 100%+ CPU while typing some "simple" code. Some small tricks to make the swift-parser quicker by the way you structure your code.
Don't use the "+" concatinator in strings. For me this triggers the slowness very quickly.
Each new "+" brings the parser to a crawl, and it has to reparse the code everytime you add a new char somewhere in your function body.
Instead of:
var str = "This" + String(myArray.count) + " is " + String(someVar)
Use the template-syntax which seems much more efficient to parse in swift:
var str = "This \(myArray.count) is \(someVar)"
This way i basically notice no limit in strlen with inline vars "\(*)" .
If you have calculations, which use + / * - then split them into smaller parts.
Instead of:
var result = pi * 2 * radius
use:
var result = pi * 2
result *= radius
It might look less efficient, but the swift parser is much faster this way.
Some formulas won't compile, if they have to many operations, even if they are mathematically correct.
If you have some complex calculations then put it in a func. This way the parser can parse it once and does not have to reparse it everytime you change something in your function body.
Because if you have a calculation in your function body then somehow the swift parser checks it everytime if the types, syntax etc. are still correct. If a line changes above the calculation, then some vars inside your calculation / formula might have changed. If you put it in an external function then it will be validated once and swift is happy that it will be correct and does not reparse it constantly, which is causing the high CPU usage.
This way i got from 100% on each keypress to low CPU while typing.
For example this 3 lines put inline in your function body can bring the swiftparser to a crawl.
let fullPath = "\(NSHomeDirectory())/Library/Preferences/com.apple.spaces.plist"
let spacesData = NSDictionary(contentsOfFile: fullPath )! // as Dictionary<String, AnyObject>
let spaces : AnyObject = spacesData["SpacesDisplayConfiguration"]!["Management Data"]!!["Monitors"]!![0]["Spaces"]!!
println ( spaces )
but if i put it in a func and call it later , swiftparser is much quicker
// some crazy typecasting here to silence the parser
// Autodetect of Type from Plist is very rudimentary,
// so you have to teach swift your types
// i hope this will get improved in swift in future
// would be much easier if one had a xpath filter with
// spacesData.getxpath( "SpacesDisplayConfiguration/Management Data/Monitors/0/Spaces" ) as Array<*>
// and xcode could detect type from the plist automatically
// maybe somebody can show me a more efficient way to do it
// again to make it nice for the swift parser, many vars and small statements
func getSpacesDataFromPlist() -> Array<Dictionary<String, AnyObject>> {
let fullPath = "\(NSHomeDirectory())/Library/Preferences/com.apple.spaces.plist"
let spacesData = NSDictionary(contentsOfFile: fullPath )! as Dictionary<String, AnyObject>
let sdconfig = spacesData["SpacesDisplayConfiguration"] as Dictionary<String, AnyObject>
let mandata = sdconfig["Management Data"] as Dictionary<String, AnyObject>
let monitors = mandata["Monitors"] as Array<Dictionary<String, AnyObject>>
let monitor = monitors[0] as Dictionary<String, AnyObject>
let spaces = monitor["Spaces"] as Array<Dictionary<String, AnyObject>>
return spaces
}
func awakeFromNib() {
....
... typing here ...
let spaces = self.getSpacesDataFromPlist()
println( spaces)
}
Swift and XCode 6.1 is still very buggy, but if you follow these simple tricks, editing code becomes acceptable again. I prefer swift a lot, as it gets rid of .h files and uses much cleaner syntax. There is still many type-casting needed like "myVar as AnyObject" , but thats the smaller evil compared to complex objective-c project structure and syntax.
Also another experience, i tried the SpriteKit, which is fun to use, but its quite in-efficient if you don't need a constant repaint at 60fps. Using old CALayers is much better for the CPU if your "sprites" don't change that often. If you don't change the .contents of the layers then CPU is basically idle, but if you have a SpriteKit app running in background, then videoplayback in other apps might start to stutter due to the hardlimited 60fps update-loop.
Sometimes xcode shows odd errors while compiling, then it helps to go into menu "Product > Clean" and compile it again, seems to be a buggy implementation of the cache.
Another great way to improve parsing when xcode gets stuck with your code is mentioned in another stackoverflow post here. Basically you copy all contents from your .swift file into an external editor, and then function by function copy it back and see where your bottleneck is. This actually helped me to get xcode to a reasonable speed again, after my project went crazy with 100% CPU. while copying your code back, you can refactor it and try to keep your function-bodies short and functions/formulars/expressions simple (or split in several lines).
Autocomplete is broken since Xcode 4. Until Apple decides to fix this 2 years old bug, the only solution, unfortunately, is to turn code completion OFF on XCode's preferences (first option of the pic below).
You can continue to enjoy completion manually by typing CTRL space or ESC when you need it.
This is the only solution that works every time for 100% of the cases.
Another thing I have discovered recently is: if you use plugins on Xcode, don't. Remove them all. They make the problem worse.
Are you using Spotify?
I installed Yosemite GM with Xcode 6.1 GM on an iMac mid 2009 (2.66Ghz) having the same problem.I found that a process called "SpotifyWebHelper" is always marked red as not responding, so i disabled the option "start from web" in spotify and now Xcode seem to run significantly better.
I found out that usually happens when you:
have long expressions in a single statement (see this answer)
mix multiple custom operators in a single expression
The 2nd case seems to be fixed in one of the latest xcode releases. Example: I defined 2 custom operators <&&> and <||>, and used in an expression like a <&&> b <&&> c <||> d. Splitting to multiple lines solved the problem:
let r1 = a <&&> b
let r2 = r1 <&&> c
let r3 = r2 <||> d
I hope that your cases is covered by one of the 2 above... please post a comment either case
I had the same issues even in Xcode 6.3
super slow autocompletions
super slow indexing
enormous CPU usage by swift and SourceKitService
enormous Memory usage by SourceKitService
All this was happening even in relatively small project. I tried all the fixes I could find:
deleting ~/Library/Developer/Xcode/DerivedData/*
deleting ~/Library/Caches/com.apple.dt.Xcode/*
remove all "+" String combining from the code
removed all suspicious dictionary declarations
None of these actually helped in my project.
What actually solved my problem was:
placing each end every class in its own file
placing each and every extension in its own file (Class+ExtName.swift)
placing "out of class swift methods" in its own file
Now I have close to zero CPU usage, low memory usage, and decently fast completions.
Generally, moving the cache folder (DerivedData) to a SSD drive (specifically in my case - an outer storage connected to thunderbolt exit) has dramatically improved my Xcode performance.. Compilation time and general wondering around the app is about 10 time faster.. Also moved the whole git folder to the SSD, which dramatically improved git performance.
It was a pain until XCode 7.2.
Apple fixed it in XCode 7.3 and now it works like a charm. It's super fast and much more powerful as it seems to work a bit like the fuzzy search of files : you don't have to actually type the exact beginning of the method/property for it to appear in the list of propositions.
Collapsing all methods helps a little.
command-alt-shift-left arrow will do the trick...
To fold/unfold current methods or if structures use:
Fold: command-alt-left arrow
Unfold: command-alt-right arrow
SourceKitService is also kinda clumsy to deal with comments in the code and the embedded comments slow it down too.
so if you can afford to remove the massive blob of embedded comments like this:
/*
* comment
/*
* embedded comment
*/
*/
that can definitely help as well.
NOTE: in my case my Xcode 7.3.1 (7D1014) was literally blocked me typing any letter when the file had about 700 lines of comment with embedded comments. initially I removed that block from that .swift file and Xcode has become alive again. I tried added my comments back part by part by removing embedded comments, it was still slower than usual but it shown significantly better performance if there were no embedded comments.
I had the same issue where typing was lagging in a particular class and turns out that
/*
Long
multiline
comments
*/
was slowing down the typing.
Related
I am trying to use C++ AMP in Visual C++ 2017 on Windows 10 (updated to the latest) and I find the archived FFT library from C++ AMP team on codeplex. I try to run the sample code, however the program throws ran out of memory error when creating DirectX FFT. I solve that problem by following the thread on Microsoft forum.
However, the problem doesn't stop. When the FFT library tries to create Unordered Access View, it throws error of CLIPBRD_E_CANT_OPEN. I did not try to operate on clipboard anyhow.
Thank you for reading this!
It seems I solve the problem. The original post mentioned that we need to create a new DirectX device and then create accelerator view upon it. Then I pass that view to ctor of fft as the second parameter.
fft(
concurrency::extent<_Dim> _Transform_extent,
const concurrency::accelerator_view& _Av = concurrency::accelerator().default_view,
float _Forward_scale = 0.0f,
float _Inverse_scale = 0.0f)
However, I still have crashes of the CLIPBRD_E_CANT_OPEN.
After reading the code, I realize that I need to create array on that DirectX views too. So I started to change:
array<std::complex<float>,dims> transformed_array(extend, directx_acc_view);
The idea comes from the different behaviors of create_uav(). The internal buffers and the precomputing caused no problem, but the samples' calls trigger the clipboard error. I guess the device matters here, so I do that change.
I hope my understanding is correct and anyway there is no such errors now.
Using this class I am trying to load a gif url into UIImageView.
The thing is , for some url's it takes 10 seconds to load, others 2 seconds.
I have tried almost anything, but still the process is too slow. 1 second would be good, but i had never succeed getting there.
I have also tried with UIWebview which had its own issues .
Here is the code :
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)) {
let fileUrl = NSURL(string:"http://45.media.tumblr.com/6785bae27b8f888fe825f0ade95796a3/tumblr_noenkbeTSw1qjmwryo1_500.gif" )
let gif = UIImage.animatedImageWithAnimatedGIFURL(fileUrl!)
dispatch_async(dispatch_get_main_queue()) {
self.player.image = gif
}
}
The problem with most of the GIF reading tools I have looked at is that they read all the data in at load time and that they allocate memory for all of the decoded frames and hold all that uncompressed data in memory at the same time. This will lead to runtime performance problems and it will crash your app and possibly your device on large/long gifs. On the issue of loading time, there is not all that much you can do since the data does need to be downloaded and read. You are also just assuming that the network cache is going to handle hitting the same GIF over and over without going to the network again, which may or may not work well for you. For a solution that addresses these issues, see this SO Question or you can also take a look at the flipboard solution here.
I would like to be able to redirect my logging statements to a file so that I can retrieve them when my app runs standalone (i.e. is not attached to Xcode). I have discovered (thank you Stackoverflow) that freopen can be used to accomplish this.
If I create a new Xcode project and add the code to redirect stderr then everything works as expected.
However, when I add the redirection code to my existing, bluetooth project I am having trouble. The file is being created and I can retrieve it using iTunes or Xcode's Devices window, but it is of size 0. If I explicitly close the file then the text that I wrote actually makes it into the file. It is as though iOS is not flushing the file when the app is terminated. I suspect that the trouble stems from the fact that I have enabled background processing. Can anyone help me to understand this?
Here is my code:
let pathes = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true);
let filePath = NSURL(fileURLWithPath: pathes[0]).URLByAppendingPathComponent("Test.log")
freopen(filePath.path!, "a", stderr);
fputs("Hello, Samantha!\r\n", stderr);
struct StderrOutputStream: OutputStreamType {
static let stream = StderrOutputStream()
func write(string: String) {fputs(string, stderr)}
}
var errStream = StderrOutputStream.stream
print("Hello, Robert", toStream: &errStream)
fclose(stderr) // Without this the text does not make it into the file.
I'd leave this as a comment, but have you looked into NSFileHandle? It sounds like you just need a way to append data to the end of a text file, correct?
Once you have a handle with something like NSFileHandle(forWritingToURL:), you can use .seekToEndOfFile() and .writeData(_:). As a side note, you'll need to convert your String to Data before writing it.
Admittedly, this will probably end up being more lines of code, and you'll almost certainly need to take threading into consideration.
I'm new to Xcode and found something frustrating. I select a few lines of code and comment them out. for ex.
// NSString* u = __txtUsername.text;
// NSString* p = __txtPassword.text;
then I may re-indent the code and the commented code goes like below
// NSString* u = __txtUsername.text;
// NSString* p = __txtPassword.text;
now if I try to uncomment the commented code Xcode produces something like below
// // NSString* u = __txtUsername.text;
// // NSString* p = __txtPassword.text;
in fact instead of removing // it adds more // at the beginning and removing // from commented re-indented code is really frustrating.
Is there any solution to that or I've made something ridiculously?
You're correct, Xcode is stupid. If you get in this situation, keep hitting cmd-[ to bring the text all the way to the start of the line, then uncomment and it should work. Why Xcode doesn't just remove the first instance of // on a line is beyond me.
Editor->Structure->Uncomment Selection
the option won't show up if lines WITHOUT COMMENTS included into selection
comments must appear AT THE FIRST POSITION to be considered as such
For those who don't want to type three times, and just make normal cmd + / work, try this, I love it.
https://apps.apple.com/us/app/comment-here/id1406737173?mt=12
Download it, open it. It tells you how to install it. Also as the last step says, remove previous keymap for it, and assign a new one.
Just leave the // all the way to the left, or the uncomment feature indeed will not work.
If you need multiline comment, your best bet might be to use this syntax:
/*
NSString* u = __txtUsername.text;
NSString* p = __txtPassword.text;
*/
Then you only have to delete /* and */ to uncomment the block of code.
If I have to comment-out a non-trivial amount of code I use:
#if 0
code
code
code
#endif // 0
If it's a trivial amount of code I do it manually. This is hardly manual labour compared to some jobs, so I don't mind this.
I've never used the (un)comment-out command on any IDE.
So long as you ONLY highlight the exact lines that are commented out, the "uncomment" function should work just fine. If you highlight the commented code beyond the confines of the uncommented code, then it treats it as if you're "adding to" the already-commented out code. Which, as you know re-indents and re-comments out the already-commented out code, if that makes sense. There shouldn't be any need to mess with indentation... Xcode should put everything right back in the correct place.
I like the "/*... */" concept from woz though. I'd like it more if there was a keyboard shortcut that would make that method a little faster. Quickly highlighting anywhere w/in the row, then pressing the "cmd /" keystroke seems a little less precise and faster for me.
Not sure if this has been fixed on Xcode since this posting, but thought I'd comment on it.
Good luck all.
I currently have some code as shown below that uses Linq to organize some IEnumerables for me. When executing this code on the device in release mode (iOS 5.0.1, MonoTouch 5.0.1, Mono 2.10.6.1) I get the exception
Attempting to JIT compile method 'System.Linq.OrderedEnumerable`1:GetEnumerator()' while running with --aot-only.
The code that generates this error is
// List<IncidentDocument> documents is passed in
List<LibraryTableViewItemGroup> groups = new List<LibraryTableViewItemGroup>();
List<DocumentObjectType> categories = documents.Select(d=>d.Type).Distinct().OrderBy(s=>s.ToString()).ToList();
foreach(DocumentObjectType cat in categories)
{
List<IncidentDocument> catDocs = documents.Where(d => d.Type == cat).OrderBy(d => d.Name).ToList();
List<LibraryTableViewItem> catDocsTableItems = catDocs.ConvertAll(d => { return new LibraryTableViewItem{ Image = GetImageForDocument(d.Type), Title = d.Name, SubTitle = d.Description}; });
LibraryTableViewItemGroup catGroup = new LibraryTableViewItemGroup{ Name = GetCatName(cat), Footer = null, Items = catDocsTableItems };
groups.Add (catGroup);
}
This error doesn't happen in the simulator for Release|Debug configurations, or on the device for the Debug configuration. I've seen a couple of similar threads on SO here and here, but I'm not sure I understand how they apply to me on this particular issue.
It could be a few things.
There are some limitations when using full AOT to build iOS applications, i.e. ensuring that nothing will be JITted at runtime (an Apple restriction). Each one is different even if the message looks identical (i.e. many causes will lead to this). However there are generally easy workarounds we can suggest for them;
It could also be a (known) regression in 5.0.1 (which is fixed in 5.0.2). This produced a few extra AOT failures that are normally not issues (or already fixed issues).
I suggest you to update to MonoTouch 5.0.2 to see if it compiles correctly your application. If not then please fill a bug report on http;//bugzilla.xamarin.com and include a small, self-contained, test case to duplicate the issue (the above is not complete enough). It seems an interesting test case if it works when debugging is enabled.