ios - Xcode 6 con escritura rápida súper lenta y autocompletado

autocomplete swift

Question

¿Soy solo yo o Xcode 6 (6.0.1) con Swift parece ser súper lento cuando escribe su código, especialmente con autocompletado?

Una clase normal de Objective-C, incluso dentro de un proyecto Swift, funciona casi igual que antes, por lo que es Swift quien la mata.

¿Alguien más experimenta los mismos inconvenientes? ¿Tienes alguna idea de cómo mejorar el rendimiento?

• Traté de jugar con algunos ajustes pero no tuve suerte.
• Por supuesto, también he intentado reiniciar Xcode y la computadora sin suerte.
• No hay otras aplicaciones pesadas abiertas.

Utilizo una Macbook Pro de mediados de 2009 (Intel Core 2 Duo de 2.26 GHz) con 8GB de RAM y SSD HD, que no es lo más nuevo, pero aún no es una basura completa.

Es una pena, ya que estaba emocionado de comenzar a usar Swift y ahora es realmente insoportable.

Pensamientos / consejos?

Answer 1

¿Estás usando Spotify? Instalé Yosemite GM con Xcode 6.1 GM en un iMac a mediados de 2009 (2.66Ghz) que tenía el mismo problema. Descubrí que un proceso llamado "SpotifyWebHelper" siempre está marcado en rojo como no responde, así que desactivé la opción "iniciar desde la web" en Spotify y ahora Xcode parecen funcionar significativamente mejor.

Answer 2

Colapsar todos los métodos ayuda un poco.

La flecha comando-alt-shift-izquierda hará el truco ...

Para plegar / desplegar métodos actuales o si las estructuras usan:

Pliegue: comando-alt-flecha izquierda

Desplegar: comando-alt-flecha derecha

Answer 3

Descubrí que generalmente sucede cuando usted:

• tener expresiones largas en una sola declaración (ver esta respuesta )
• mezclar múltiples operadores personalizados en una sola expresión

El segundo caso parece estar solucionado en una de las últimas versiones de xcode. Ejemplo: definí 2 operadores personalizados <&&> y <||>, y los utilicé en una expresión como a <&&> b <&&> c <||> d . La división en varias líneas resolvió el problema:

let r1 = a <&&> b
let r2 = r1 <&&> c
let r3 = r2 <||> d

Espero que sus casos estén cubiertos por uno de los 2 anteriores ... publique un comentario en cualquiera de los casos

Answer 4

El autocompletado está roto desde Xcode 4. Hasta que Apple decida arreglar este error de 2 años, la única solución, desafortunadamente, es desactivar la finalización del código en las preferencias de XCode (primera opción de la imagen a continuación).

Puede continuar disfrutando de la finalización manualmente escribiendo CTRL space o ESC cuando lo necesite.

Esta es la única solución que funciona siempre para el 100% de los casos.

Otra cosa que he descubierto recientemente es: si usa complementos en Xcode, no lo haga. Eliminarlos a todos. Empeoran el problema.

Answer 5

En general, mover la carpeta de caché (DerivedData) a una unidad SSD (específicamente en mi caso, un almacenamiento externo conectado a la salida de rayo) ha mejorado drásticamente mi rendimiento de Xcode. El tiempo de compilación y las preguntas generales sobre la aplicación es aproximadamente 10 veces más rápido. También movió toda la carpeta git al SSD, lo que mejoró drásticamente el rendimiento de git.

Answer 6

Fue un dolor hasta XCode 7.2.

Apple lo arregló en XCode 7.3 y ahora funciona de maravilla. Es súper rápido y mucho más poderoso, ya que parece funcionar un poco como la búsqueda difusa de archivos: no tiene que escribir el comienzo exacto del método / propiedad para que aparezca en la lista de proposiciones.

Answer 7

También experimenté 100% + CPU mientras escribía un código "simple". Algunos pequeños trucos para acelerar el análisis rápido por la forma en que estructura su código.

No use el concatinador "+" en cadenas. Para mí, esto desencadena la lentitud muy rápidamente. Cada nuevo "+" lleva el analizador a un rastreo, y tiene que volver a analizar el código cada vez que agrega un nuevo carácter en algún lugar de su cuerpo de función.

En lugar de:

var str = "This" + String(myArray.count) + " is " + String(someVar)

Utilice la sintaxis de plantilla, que parece mucho más eficiente para analizar rápidamente:

var str = "This /(myArray.count) is /(someVar)"

De esta manera, básicamente no noto ningún límite en strlen con vars en línea "/ (*)".

Si tiene cálculos, que usan + / * - luego divídalos en partes más pequeñas.

En lugar de:

var result = pi * 2 * radius 

utilizar:

var result  = pi * 2
    result *= radius

Puede parecer menos eficiente, pero el analizador rápido es mucho más rápido de esta manera. Algunas fórmulas no se compilarán si tienen muchas operaciones, incluso si son matemáticamente correctas.

Si tiene algunos cálculos complejos, póngalo en una función. De esta manera, el analizador puede analizarlo una vez y no tiene que volver a analizarlo cada vez que cambie algo en su cuerpo funcional.

Porque si tiene un cálculo en el cuerpo de su función, de alguna manera el analizador rápido lo comprueba cada vez si los tipos, la sintaxis, etc., siguen siendo correctos. Si una línea cambia por encima del cálculo, algunos valores dentro de su cálculo / fórmula podrían haber cambiado. Si lo coloca en una función externa, se validará una vez y Swift está feliz de que sea correcto y no lo vuelva a analizar constantemente, lo que está causando un alto uso de la CPU.

De esta manera, pasé del 100% en cada pulsación de tecla a CPU baja mientras escribía. Por ejemplo, estas 3 líneas puestas en línea en el cuerpo de su función pueden arrastrar el 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 )

pero si lo pongo en un func y lo llamo más tarde, swiftparser es mucho más rápido

// 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 y XCode 6.1 todavía tienen muchos errores, pero si sigues estos simples trucos, la edición del código vuelve a ser aceptable. Prefiero bastante rápido, ya que elimina los archivos .h y usa una sintaxis mucho más limpia. Todavía se necesitan muchos tipos de conversión como "myVar como AnyObject", pero esa es la maldad más pequeña en comparación con la compleja estructura y sintaxis del proyecto objetivo-c.

También otra experiencia, probé el SpriteKit, que es divertido de usar, pero es bastante eficiente si no necesita un repintado constante a 60 fps. Usar viejos CALayers es mucho mejor para la CPU si tus "sprites" no cambian con tanta frecuencia. Si no cambia el contenido de las capas, entonces la CPU está básicamente inactiva, pero si tiene una aplicación SpriteKit ejecutándose en segundo plano, la reproducción de video en otras aplicaciones podría comenzar a tartamudear debido al ciclo de actualización de 60 fps ilimitado.

A veces, xcode muestra errores extraños durante la compilación, luego ayuda a ir al menú "Producto> Limpiar" y compilarlo nuevamente, parece ser una implementación defectuosa del caché.

Otra excelente forma de mejorar el análisis cuando xcode se atasca con su código se menciona en otra publicación de here . Básicamente, copie todo el contenido de su archivo .swift en un editor externo, y luego, función por función, vuelva a copiarlo y vea dónde está su cuello de botella. Esto realmente me ayudó a llevar xcode a una velocidad razonable nuevamente, después de que mi proyecto se volvió loco con 100% de CPU. Al copiar su código, puede refactorizarlo e intentar mantener sus cuerpos de funciones cortos y las funciones / formuladores / expresiones simples (o divididas en varias líneas).

Answer 8

Tuve el mismo problema en el que la mecanografía estaba retrasada en una clase en particular y resulta que

/* Long multiline comments */

estaba ralentizando la escritura.

Answer 9

Tuve los mismos problemas incluso en Xcode 6.3

• autocompletados súper lentos
• indexación súper lenta
• enorme uso de CPU por swift y SourceKitService
• enorme uso de memoria por SourceKitService

Todo esto sucedía incluso en proyectos relativamente pequeños. Intenté todas las soluciones que pude encontrar:

• eliminar ~ / Library / Developer / Xcode / DerivedData / *
• eliminar ~ / Library / Caches / com.apple.dt.Xcode / *
• eliminar toda la combinación de cadenas "+" del código
• eliminó todas las declaraciones sospechosas del diccionario

Ninguno de estos realmente ayudó en mi proyecto.

Lo que realmente resolvió mi problema fue:

• colocando cada extremo de cada clase en su propio archivo
• colocando cada extensión en su propio archivo (Class + ExtName.swift)
• colocando "métodos rápidos fuera de clase" en su propio archivo

Ahora tengo un uso de CPU cercano a cero, bajo uso de memoria y terminaciones decentemente rápidas.

Answer 10

SourceKitService también es un poco torpe para manejar los comentarios en el código y los comentarios incrustados también lo ralentizan.

así que si puedes permitirte eliminar la gran cantidad de comentarios incrustados como este:

/*
 * comment 
    /*
     * embedded comment
     */
 */

eso definitivamente puede ayudar también.

NOTA: en mi caso, mi Xcode 7.3.1 (7D1014) literalmente me bloqueó al escribir cualquier letra cuando el archivo tenía aproximadamente 700 líneas de comentarios con comentarios incrustados. Inicialmente .swift ese bloque de ese archivo .swift y Xcode ha cobrado vida nuevamente. Intenté volver a agregar mis comentarios parte por parte eliminando los comentarios incrustados, aún era más lento de lo habitual, pero mostró un rendimiento significativamente mejor si no hubiera comentarios incrustados.

Answer 11

• Salir de Xcode y reiniciar la Mac no es obligatorio pero sí preferido.
• Eliminar el contenido de la carpeta ~ / Library / Developer / Xcode / DerivedData
• Eliminar el contenido ~ / Library / Caches / com.apple.dt.Xcode

Esta es una solución temporal, pero funciona en gran medida.

Debajo del script usando la aplicación Script Editor.

tell application "Terminal"
    do script "rm -frd ~/Library/Developer/Xcode/DerivedData/*"
    do script "rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
end tell

Alternativamente, puede crear un alias para su terminal como este:

alias xcodeclean="rm -frd ~/Library/Developer/Xcode/DerivedData/* && rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"

Puede agregar eso a su ~/.bash_profile y luego escribir xcodeclean en la línea de comando cada vez que desee borrar esas dos carpetas.