"No use StringBuilder o foreach en esta ruta de código de acceso"

Question

Estoy navegando por el código fuente del proyecto de código abierto SignalR, y veo this diff code que tiene derecho "No use StringBuilder o foreach en este código de acceso directo camino":

-   public static string MakeCursor(IEnumerable<Cursor> cursors) 
+   public static string MakeCursor(IList<Cursor> cursors) 
      { 
-    var sb = new StringBuilder(); 
-    bool first = true; 
-    foreach (var c in cursors) 
+    var result = ""; 
+    for (int i = 0; i < cursors.Count; i++) 
       { 
-     if (!first) 
+     if (i > 0) 
        { 
-      sb.Append('|'); 
+      result += '|'; 
        } 
-     sb.Append(Escape(c.Key)); 
-     sb.Append(','); 
-     sb.Append(c.Id); 
-     first = false; 
+     result += Escape(cursors[i].Key); 
+     result += ','; 
+     result += cursors[i].Id; 
       } 
-    return sb.ToString(); 
+    return result; 
      } 

entiendo por qué foreach podría ser menos eficiente en ocasiones, y por qué es reemplazado por de.

Sin embargo, aprendí y experimenté que StringBuilder es la forma más eficiente de concatenar cadenas. Así que me pregunto por qué el autor decidió reemplazarlo con concatenación estándar.

¿Qué hay de malo aquí y en general sobre el uso de StringBuilder?

Answer 1

Hice el cambio de código y sí, hizo una gran diferencia en el número de asignaciones (GetEnumerator()) llamadas vs no. Imagine que este código es millones de veces por segundo. La cantidad de enumeradores asignados es ridícula y se puede evitar.

edición: Ahora invertimos de control con el fin de evitar cualquier asignación (escribir al escritor directa): https://github.com/SignalR/SignalR/blob/2.0.2/src/Microsoft.AspNet.SignalR.Core/Messaging/Cursor.cs#L36

Answer 2

¿Cuántas concatenaciones estás haciendo? Si es numeroso, use StringBuilder. Si solo unos pocos, la sobrecarga de crear StringBuilder superará cualquier ventaja.

Answer 3

Solo espero que el tipo que cambió esto realmente midiera la diferencia.

• Hay una sobrecarga al crear instancias de un nuevo generador de cadenas cada vez. Esto también ejerce presión sobre la recolección de memoria/basura.
• El compilador puede generar código 'stringbuilderlike' para concatenaciones simples
• El PARA realidad podría ser más lenta, ya que podría requerir comprobación de límites que no se hace con foreach como los compiladores 'sabe' que estén dentro de los límites.

Answer 4

voy a poner mi dinero en

  StringBuilder sb = new StringBuilder(); 
      bool first = true; 
      foreach (Cursor c in cursors) 
      { 
       if (first) 
       { 
        first = false; // only assign it once 
       } 
       else 
       { 
        sb.Append('|'); 
       } 
       sb.Append(Escape(c.Key) + ',' + c.Id); 
      } 
      return sb.ToString(); 

Pero yo pondría mi dinero y la actualización de dfowler. Mira el enlace en su respuesta.

Answer 5

Depende del número de Cursor proporcionados a la función.

La mayoría de las comparaciones entre los dos apporaches parecen favorecer StringBuilder sobre la concatinación de cuerdas cuando se concatenan 4-10 cuerdas. Lo más probable es que esté a favor de StringBuilder si no tuviera motivos explícitos (por ejemplo, comparación de rendimiento de los dos enfoques para mi problema/aplicación). Consideraría preasignar un buffer en el StringBuilder para evitar (muchas) reasignaciones.

Para más información sobre el tema, ver String concatenation vs String Builder. Performance y Concatenating with StringBuilders vs. Strings.