.net - para - c# android

¿Las interfaces fluidas afectan significativamente el rendimiento del tiempo de ejecución de una aplicación.NET?

Question

Actualmente me estoy ocupando de implementar una interfaz fluida para una tecnología existente, que permitiría un código similar al siguiente fragmento:

using (var directory = Open.Directory(@"path/to/some/directory"))
{
    using (var file = Open.File("foobar.html").In(directory))
    {
        // ...
    }
}

Para implementar dichos constructos, se necesitan clases que acumulen argumentos y los pasen a otros objetos. Por ejemplo, para implementar Open.File(...).In(...) construir, necesitaría dos clases:

// handles ''Open.XXX'':
public static class OpenPhrase
{
    // handles ''Open.File(XXX)'':
    public static OpenFilePhrase File(string filename)
    {
        return new OpenFilePhrase(filename);
    }

    // handles ''Open.Directory(XXX)'':
    public static DirectoryObject Directory(string path)
    {
        // ...
    }
}

// handles ''Open.File(XXX).XXX'':
public class OpenFilePhrase
{
    internal OpenFilePhrase(string filename)
    {
        _filename = filename
    }

    // handles ''Open.File(XXX).In(XXX):
    public FileObject In(DirectoryObject directory)
    {
        // ...
    }

    private readonly string _filename;
}

Es decir, cuantas más partes constituyentes tengan los enunciados, como los ejemplos iniciales, más objetos necesitan crearse para pasar argumentos a los objetos posteriores de la cadena hasta que la declaración real pueda finalmente ejecutarse.

Pregunta:

Me interesan algunas opiniones: ¿una interfaz fluida que se implementa utilizando la técnica anterior tiene un impacto significativo en el rendimiento del tiempo de ejecución de una aplicación que lo usa? Con el rendimiento del tiempo de ejecución, me refiero a los aspectos de velocidad y uso de la memoria.

Tenga en cuenta que un número potencialmente grande de objetos temporales, que ahorran argumentos, debería crearse solo para tiempos breves, lo que supongo que puede ejercer cierta presión sobre el recolector de basura.

Si cree que hay un impacto significativo en el rendimiento, ¿conoce alguna forma mejor de implementar interfaces fluidas?

Answer 1

En términos generales, los objetos con una vida útil muy pequeña son exactamente el tipo de objetos con los que el GC trata de manera más eficiente, porque la mayoría de ellos estarán muertos en el momento en que se ejecuta la siguiente colección menor, y en cualquier implementación de GC decente, el costo de una colección menor es proporcional al tamaño total de los objetos vivos . Por lo tanto, los objetos efímeros cuestan muy poco, y su asignación significa solo disparar un puntero hacia arriba, que es rápido.

Entonces diría: probablemente no tenga un impacto significativo en el rendimiento.

Answer 2

Thomas tiene razón en que el GC generacional está optimizado para exactamente esta asignación y colección de objetos efímeros. Sin embargo, los lenguajes funcionales como OCaml tienen GC que están mucho más optimizados para esto que .NET y, sin embargo, todavía hacen grandes esfuerzos para evitar esta situación en la circunstancia equivalente de aplicar múltiples argumentos a una función curried. Específicamente, utilizan una técnica llamada semántica de gran paso en la que el compilador elimina todos los intermedios en tiempo de compilación para que el GC nunca vea nada de esto.

En .NET, los tipos de valores bien pueden permitirle resolver este problema usted mismo.