Objeto en VB 2010 ha recibido la misma Optimización dinámica como en C # 4.0?

Question

Algunas personas han argumentado que la característica de C # 4.0 introducida con la palabra clave dynamic es el mismo que el "todo es un objeto" característica de VB. Sin embargo, cualquier llamada en una variable dinámica se traducirá en un delegado de una vez y de ahí en adelante, se llamará el delegado. En VB, al utilizar Object, no el almacenamiento en caché se aplica y cada llamada en un método no mecanografiado implica una gran cantidad de bajo el capó reflexión, a veces por un total de un 400 plegable pena friolera rendimiento.

Haga que el tipo dinámico delegado optimización y almacenamiento en caché de también han añadido a la VB llamadas a métodos sin tipo, o es objeto sin tipo de VB sigue siendo tan lento?

Answer 1

Solución

Algunas investigaciones y una mejor lectura de la referido antes al artículo mencionado por Hans Passant, trae consigo la siguiente conclusión:

• VB.NET 2010 admite el DLR;
• Se puede aplicar IDynamicMetaObjectProvider si quieres apoyar explícitamente la dinámica, el compilador de VB.NET se actualiza para reconocer que;
• Object de VB sólo utilizar el DLR y el método de almacenamiento en caché si los implementos de objeto IDynamicMetaObjectProvider;
• BCL y chasis tipos no implementan IDynamicMetaObjectProvider, utilizando Object en tales tipos o sus propios tipos invocará el caché no VB.NET finales del ligante clásico,.

Antecedentes: elaborar sobre por qué enlace tardío almacenamiento en caché podría ayudar el rendimiento del código VB

Algunas personas (entre los cuales Hans Passant, ver su respuesta) puede preguntarse por qué el almacenamiento en caché o no el almacenamiento en caché en cuestión podría posiblemente la ligadura dinámica. En realidad, hace una gran diferencia, tanto en VB y en otras tecnologías de unión a finales de los años (recuerde IQueryInterface con COM?).

Late de unión se reduce a un principio simple: dado un nombre y su parámetro-declaraciones, bucle a través de todos los métodos de esta clase y sus clases de padres por medio de los métodos disponibles, aunque la interfaz Type (y en VB, un método , una propiedad y un campo pueden mirada de la misma, por lo que este proceso aún más lento). Si se tiene en cuenta que las tablas de métodos no están ordenados, entonces esto es fácilmente mucho más caro que una sola (es decir, a máquina) llamada al método directo.

Si usted fuera capaz de buscar el método de una vez, y luego almacenar el método de puntero en una tabla de búsqueda, esto puede acelerar enormemente este proceso. vinculante en el DLR método de caché va un paso futher y reemplaza el método de llamada con un puntero al método actual, si es posible. Después de la primera llamada, esto se convierte en un orden de magnitud más rápido para cada llamada posterior (piensa 200x 800x veces más rápido).

Como un ejemplo de cuando esto es importante, aquí hay algo de código que ilustra este problema. En un caso en el que cada clase tiene una propiedad de cadena .Name, pero las clases no comparten un ancestro común o interfaz, puede inocentemente ordenar las listas de cualquiera de esos tipos, así:

' in the body of some method '
List<Customers> listCustomers = GetListCustomers()
List<Companies> listCompanies = GetListCompanies()

listCustomers.Sort(MySort.SortByName)
listCompanies.Sort(MySort.SortByName)

' sorting function '
Public Shared Function SortByName(Object obj1, Object obj2) As Integer
    ' for clarity, check for equality and for nothingness removed '    
    return String.Compare(obj1.Name, obj2.Name)    
End Function

Este código (similar al menos) en realidad hizo en la producción con uno de mis clientes y se utilizó en una frecuencia llamada de devolución de llamada AJAX. Sin almacenamiento en caché de forma manual las propiedades .Name, que ya están en las listas de tamaño medio de menos de medio millón de objetos, el código de enlace tardío se convirtió en una carga tan notable que con el tiempo llevó todo el sitio abajo. Resultó difícil de localizar a este problema, pero eso es una historia para otro momento. Después de la fijación de este, el sitio recuperó 95% de sus Resouces CPU.

Por lo tanto, la respuesta a la pregunta de Hans "no tiene problemas más grandes que preocuparse por" es simple: esto es un gran problema (o puede ser), esp. a los programadores de VB que se han metido demasiado descuidado sobre el uso de enlace tardío.

En este caso en particular, y muchos como ellos, VB.NET 2010 aparentemente no ha sido actualizado para introducir enlace tardío, y como tal, sigue siendo Object mal por el inconsciente y no debe ser comparado con dynamic.

PS:.-Finales vinculantes problemas de rendimiento son muy difíciles de localizar, a menos que tenga un generador de perfiles de rendimiento bueno y saber cómo enlace tardío se implementa internamente por el compilador

Answer 2

lo que es nuevo artículo :

  

Visual Basic 2010 se ha actualizado a   totalmente compatible con el DLR en su   latebinder

No se puede obtener más explícito que eso. Es el DLR que implementa el almacenamiento en caché.

Answer 3

Buena pregunta. Supongo que la respuesta es "no", porque este artículo en la revista de MSDN dice VB.Net se ha cambiado para apoyar la dinámica Language Runtime, y describe brevemente los cambios en el tiempo de ejecución, pero no menciona el almacenamiento en caché.

¿alguien sabe mejor?