Pregunta consideración de rendimiento cuando se utilizan propiedades varias veces


estoy usando CultureInfo.CurrentCulture Al formar mis cuerdas usando string.format

Citar este blog

Esto solo tiene la implicación de que si   estás usando CurrentCulture mucho,   podría valer la pena leerlo en una   variable privada en lugar de hacer   muchas llamadas a   CultureInfo.CurrentCulture, de lo contrario   estás usando ciclos de reloj   innecesariamente.

según este autor

var culture = CultureInfo.CurrentCulture
string.Format(culture,"{0} some format string","some args");
string.Format(culture,"{0} some format string","some other args");

es mejor que

string.Format(CultureInfo.CurrentCulture,"{0} some format string","some args");
string.Format(CultureInfo.CurrentCulture,"{0} some format string","some other args");

según MSDN, CultureInfo.CurrentCulture es una propiedad.

¿Hay una penalización de rendimiento asociada al acceder a una propiedad varias veces?

También realicé un análisis empírico y mis pruebas me muestran que usar una variable local es más costoso que usar la propiedad directamente.

Stopwatch watch = new Stopwatch();

            int count = 100000000;
            watch.Start();
            for(int i=0;i<count;i++)
            {
                string.Format(CultureInfo.CurrentCulture, "{0} is my name", "ram");
            }


            watch.Stop();
                 //EDIT:Reset watch
                 watch.Reset();


            Console.WriteLine(watch.Elapsed);
            Console.WriteLine(watch.ElapsedMilliseconds);
            Console.WriteLine(watch.ElapsedTicks);


            Console.WriteLine("--------------------");
            var culture = CultureInfo.CurrentCulture;
            watch.Start();
            for (int i=0; i < count; i++)
            {
                string.Format(culture, "{0} is my name", "ram");
            }


            watch.Stop();

            Console.WriteLine(watch.Elapsed);
            Console.WriteLine(watch.ElapsedMilliseconds);
            Console.WriteLine(watch.ElapsedTicks);

Resultado:

00:00:29.6116306
29611
68922550970
--------------------
00:00:27.3578116
27357
63676674390

Mis pruebas muestran que usando CultureInfo.CurrentCulture la propiedad es mejor que usar una variable local (lo que contradice la vista de los autores). ¿O me estoy perdiendo algo aquí?

Edición: no estaba reiniciando el cronómetro antes de la segunda iteración. De ahí la diferencia. restablecer el cronómetro, actualizar el recuento de iteraciones y dar como resultado esta edición


5
2018-02-08 16:51


origen


Respuestas:


Hay un error en su código. En su código de prueba, no reinicia el cronómetro. Cuando reinicie el cronómetro, verá que usar la referencia en caché es realmente más rápido. CultureInfo.CurrentCulture no es barato, pero string.Format es mucho más costoso.


2
2018-02-16 07:56



La única razón verdadera para reescribir tu código

var culture = CultureInfo.CurrentCulture;
String.Format(culture, "{0} some format string", "some args"); 
String.Format(culture, "{0} some format string", "some other args"); 

de

String.Format(CultureInfo.CurrentCulture, "{0} some format string", "some args");  
String.Format(CultureInfo.CurrentCulture, "{0} some format string", "some other args"); 

Es por legibilidad y mantenibilidad. Ahora, si necesita alguna razón para cambiar la cultura de CultureInfo.CurrentCulture a un CultureInfo que se carga a través de algún archivo de configuración o se pasa como un método al parámetro, solo necesita cambiar el código en un solo lugar. El desempeño es una consideración secundaria aquí y probablemente no importa, ya que es muy poco probable que esto sea un cuello de botella en su código.


7
2018-02-08 16:55



Solo debe optimizar CultureInfo.CurrentCulture en una variable local si un generador de perfiles muestra que es un problema importante en su código y también que agregar una variable local lo hace más rápido. Este perfil muestra que ninguno de los dos es verdadero, así que no lo pondría en un local.


3
2018-02-08 16:55



Preguntas populares