Podczas pisania jakiegoś „prostego” kodu doświadczyłem również 100% + CPU. Kilka drobnych sztuczek, dzięki którym szybki parser będzie szybszy dzięki strukturze Twojego kodu.
Nie używaj konkatinatora „+” w łańcuchach. Dla mnie to bardzo szybko wyzwala powolność. Każde nowe „+” przenosi parser do przeszukiwania i musi ponownie przeanalizować kod za każdym razem, gdy dodajesz nowy znak gdzieś w treści funkcji.
Zamiast:
var str = "This" + String(myArray.count) + " is " + String(someVar)
Użyj składni szablonu, która wydaje się znacznie wydajniejsza do analizowania w szybkim tempie:
var str = "This \(myArray.count) is \(someVar)"
W ten sposób zasadniczo nie zauważam ograniczenia w strlen z wbudowanymi zmiennymi "\ (*)".
Jeśli masz obliczenia, które używają + / * -, podziel je na mniejsze części.
Zamiast:
var result = pi * 2 * radius
posługiwać się:
var result = pi * 2
result *= radius
Może wyglądać na mniej wydajne, ale szybki parser jest w ten sposób znacznie szybszy. Niektóre formuły się nie skompilują, jeśli mają wiele operacji, nawet jeśli są matematycznie poprawne.
Jeśli masz jakieś złożone obliczenia, umieść je w func. W ten sposób parser może go przeanalizować raz i nie musi go ponownie analizować za każdym razem, gdy zmieniasz coś w treści funkcji.
Ponieważ jeśli masz obliczenia w treści swojej funkcji, to w jakiś sposób szybki parser sprawdza je za każdym razem, czy typy, składnia itp. Są nadal poprawne. Jeśli linia zmieni się powyżej obliczenia, to niektóre zmienne w obliczeniu / wzorze mogły ulec zmianie. Jeśli umieścisz go w funkcji zewnętrznej, zostanie zweryfikowany raz i szybko jest zadowolony, że będzie poprawny i nie będzie go stale analizować, co powoduje wysokie zużycie procesora.
W ten sposób uzyskałem od 100% przy każdym naciśnięciu klawisza do niskiego poziomu procesora podczas pisania. Na przykład te 3 wiersze umieszczone w treści funkcji mogą doprowadzić do indeksowania swiftparser.
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 )
ale jeśli wstawię go do funkcji func i zadzwonię później, swiftparser jest znacznie szybszy
// 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 i XCode 6.1 są nadal bardzo błędne, ale jeśli zastosujesz się do tych prostych sztuczek, edycja kodu znów stanie się akceptowalna. Wolę szybki, ponieważ pozbywa się plików .h i używa znacznie czystszej składni. Wciąż jest wiele potrzebnych do rzutowania typów, takich jak "myVar as AnyObject", ale to jest mniejsze zło w porównaniu ze złożoną strukturą i składnią projektu obiektywnego c.
Inne doświadczenie, wypróbowałem SpriteKit, który jest przyjemny w użyciu, ale jest dość nieefektywny, jeśli nie potrzebujesz ciągłego malowania przy 60 klatkach na sekundę. Używanie starych CALayers jest o wiele lepsze dla procesora, jeśli twoje "duszki" nie zmieniają się tak często. Jeśli nie zmienisz zawartości .contents warstw, procesor jest w zasadzie bezczynny, ale jeśli masz aplikację SpriteKit działającą w tle, odtwarzanie wideo w innych aplikacjach może zacząć się zacinać z powodu sztywnej pętli aktualizacji 60 klatek na sekundę.
Czasami xcode wyświetla dziwne błędy podczas kompilacji, wtedy pomocne jest przejście do menu „Produkt> Wyczyść” i ponowne skompilowanie. Wydaje się, że jest to błędna implementacja pamięci podręcznej.
Kolejny świetny sposób na ulepszenie analizowania, gdy xcode utknie w kodzie, jest wspomniany w innym poście dotyczącym stackoverflow tutaj . Zasadniczo kopiujesz całą zawartość z pliku .swift do zewnętrznego edytora, a następnie kopiujesz ją z powrotem za pomocą funkcji i sprawdzasz, gdzie jest twoje wąskie gardło. To faktycznie pomogło mi przywrócić xcode do rozsądnej szybkości po tym, jak mój projekt oszalał ze 100% procesorem. kopiując swój kod z powrotem, możesz go refaktoryzować i starać się, aby ciała funkcji były krótkie, a funkcje / formuły / wyrażenia proste (lub podzielone na kilka wierszy).
