Объект получил в 2010 VB тот же optimalization как динамичный в C# 4.0?

Решение

Некоторое исследование и лучшее чтение , ранее упомянутого в статье , упомянутой Хансом Пассантом, приводит к следующему выводу:

• VB.NET 2010 поддерживает DLR;
• Вы можете реализовать IDynamicMetaObjectProvider , если хотите явно поддерживать динамику, компилятор VB.NET обновлен, чтобы распознавать это;
• VB Object будет использовать DLR и кэширование методов, только если объект реализует IDynamicMetaObjectProvider ;
• Типы BCL и Framework не реализуют IDynamicMetaObjectProvider , использование Object для таких типов или ваших собственных типов вызовет классические, не- кешированный VB.NET с поздним связыванием.

Предпосылки: уточнение того, почему кеширование с поздним связыванием может помочь производительности кода VB.

Некоторые люди (среди которых Ханс Пассант, см. Его ответ) могут задаться вопросом, почему кеширование или отсутствие кеширования при позднем связывании может иметь значение. На самом деле, это имеет большое значение как в VB, так и в других технологиях позднего связывания (помните IQueryInterface с COM?).

Позднее связывание сводится к простому принципу: учитывая имя и его объявления параметров, перебрать в цикле все методы этого класса и его родительских классов с помощью методов, доступных через интерфейс Type ( а в VB метод, свойство и поле могут выглядеть одинаково, что делает этот процесс еще медленнее). Если вы считаете, что таблицы методов неупорядочены, то это намного дороже, чем один прямой (т. Е. Типизированный) вызов метода.

Если бы вы могли найти метод один раз, а затем сохранить указатель метода в таблице поиска, это значительно ускорило бы этот процесс. Привязка кэшированного метода в DLR идет на один шаг дальше и заменяет вызов метода указателем на фактический метод, если это возможно. После первого вызова это становится на порядок быстрее для каждого последующего вызова (подумайте, в 200-800 раз быстрее).

В качестве примера того, когда это имеет значение, вот код, который иллюстрирует эту проблему. В случае, когда каждый класс имеет строковое свойство .Name , но классы не имеют общего предка или интерфейса, вы можете наивно отсортировать списки любого из этих типов следующим образом:

' 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

Этот код ( по крайней мере, похожий) фактически был запущен в производство с одним из моих клиентов и использовался в часто называемом обратном вызове AJAX. Без ручного кэширования свойств .Name , уже в списках среднего размера, содержащих менее полумиллиона объектов, код с поздним связыванием стал настолько заметным бременем, что в конечном итоге привел к остановке всего сайта. Отследить эту проблему оказалось непросто, но это уже история для другого раза. После исправления этой проблемы сайт восстановил 95% ресурсов процессора.

Итак, ответ на вопрос Ханса «разве у вас нет больших проблем, о которых стоит беспокоиться?» прост: это большая проблема (или может быть), особенно. программистам VB, которые слишком небрежно подошли к использованию позднего связывания.

В этом конкретном случае и во многих подобных случаях VB.NET 2010, по-видимому, не был обновлен для введения позднего связывания, и поэтому Object остается злом для тех, кто не знает, и его не следует сравнивать с динамическим .

PS: проблемы с производительностью позднего связывания очень сложно отследить, если у вас нет хорошего профилировщика производительности и вы не знаете, как позднее связывание реализовано внутри компилятора.