Аннотация:
Использование Reflection позволяет увеличить гибкость приложения. К сожалению, использование Reflection ”в лоб” может значительно снизить производительность. В статье приводятся примеры различных способов оптимизации и производится сравнение их производительности с неоптимизированными вариантами.
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Sorry. Уже нашел.
Но вот этот текст:
> Полные исходные тексты тестовой программы и класса PerfCounter находятся на компакт-диске, прилагаемом к журналу, имя архива — ReflectionSpeedSrc.zip
Вместо dummy int-ов лучше было делать DummyClass-ы, это очень прибавило бы наглядности, а также бы точно поставило бы всех в равные положения.
Также намного легче было бы добавлять новые версии тестируемых методов.
Пример:
public class WithReflection{}
public object this[WithReflection dummy, string pName]
{
get
{
...
}
}
public class OptimizeReflection{}
public object this[OptimizeReflection dummy, string pName]
{
get
{
...
}
}
//вызовы
TestClass.WithReflection reflection = null;
...
int ti = (int)t[reflection, "IntValue"];
string si = (string)t[reflection, "StringValue"];
...
При использование делегатов совместно с индексерами лучше не пользоваться DynamicInvoke-ом.
Лучше вызывать делегаты через wrapper-ы.
пример:
//объявляем вспомогательные wrapper-ыdelegate object GetObject();
class int2object
{
public int2object(GetInt f)
{
this.f = f;
}
GetInt f;
public object Execute()
{
return f();
}
}
class string2object
{
public string2object(GetString f)
{
this.f = f;
}
GetString f;
public object Execute()
{
return f();
}
}
class DateTime2object
{
public DateTime2object(GetDateTime f)
{
this.f = f;
}
GetDateTime f;
public object Execute()
{
return f();
}
}
//заполняем hash
Delegate del = Delegate.CreateDelegate(delegateType, this, "get_" + pi.Name);
GetObject getObj = null;
switch (pi.PropertyType.Name)
{
case"string":
case"String":
{
getObj = new GetObject(new string2object((GetString)del).Execute);
break;
}
case"DateTime":
{
getObj = new GetObject(new DateTime2object((GetDateTime)del).Execute);
break;
}
default:
getObj = new GetObject(new int2object((GetInt)del).Execute);
break;
}
optimize4.Add(pi.Name, getObj);
foreach ( DispNameAttribute attr in attrs )
{
if ( optimize1[attr.DisplayName] != pi )
{
optimize4.Add(attr.DisplayName, getObj);
}
}
//вызываем делегат через индексерpublic class WithDelegate {}
public object this[WithDelegate q, string pName]
{
get
{
GetObject getter = optimize4[pName] as GetObject;
if (getter == null)
return null;
return getter();
}
}
Если способ, который вызывал делегаты через DynamicInvoke, был в 19 раз медленнее прямых delegate-ов,
то вызовы через wrapper-ы уже медленнее всего в 6 раз.
Причем есть гипотеза, что если заменить типы int, string, DateTime на классы, т.е. убрать boxing и последующий unboxing, то разрыв с прямыми делегатами еще сильнее сократится.
Wrapper-ы можно генерировать, как в дизайне, так и в runtime. Можно также попытаться воспользоваться шаблонами.
зы
Жаль, что framework (или компилятор) сам автоматически не создает такие wrapper-ы.
Здравствуйте, DarkGray, Вы писали:
DG>>На CD к журналу их нет.
DG>Sorry. Уже нашел. DG>Но вот этот текст:
>> Полные исходные тексты тестовой программы и класса PerfCounter находятся на компакт-диске, прилагаемом к журналу, имя архива — ReflectionSpeedSrc.zip
А это — не ко мне... не я же компакт писал
... << RSDN@Home 1.1.3 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
МП>Авторы: МП> Михаил Полюдов
МП>Аннотация: МП>Использование Reflection позволяет увеличить гибкость приложения. К сожалению, использование Reflection ”в лоб” может значительно снизить производительность. В статье приводятся примеры различных способов оптимизации и производится сравнение их производительности с неоптимизированными вариантами.
Режет глаза то, что не хватает самого производительного (ГИПОТЕЗА) после директа варианта — IL-генерации.
Рассказываю людям, а они делают круглые глаза, мол, это как это так ?!
МП>>Авторы: МП>> Михаил Полюдов
МП>>Аннотация: МП>>Использование Reflection позволяет увеличить гибкость приложения. К сожалению, использование Reflection ”в лоб” может значительно снизить производительность. В статье приводятся примеры различных способов оптимизации и производится сравнение их производительности с неоптимизированными вариантами.
T>Режет глаза то, что не хватает самого производительного (ГИПОТЕЗА) после директа варианта — IL-генерации. T>Рассказываю людям, а они делают круглые глаза, мол, это как это так ?!
действительно очень странно — так как использовать заранее созданные делегаты это уже не рефлекшин и сравнивать этот способ с получением значения по именни как то не коректно
Здравствуйте, TATAPuH, Вы писали:
T>>Режет глаза то, что не хватает самого производительного (ГИПОТЕЗА) после директа варианта — IL-генерации. T>>Рассказываю людям, а они делают круглые глаза, мол, это как это так ?!
TAT>действительно очень странно — так как использовать заранее созданные делегаты это уже не рефлекшин и сравнивать этот способ с получением значения по именни как то не коректно
Вы бы еще более древнюю статью выбрали бы и изумлялись бы, что ж так бедно-то...
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, TATAPuH, Вы писали:
T>>>Режет глаза то, что не хватает самого производительного (ГИПОТЕЗА) после директа варианта — IL-генерации. T>>>Рассказываю людям, а они делают круглые глаза, мол, это как это так ?!
TAT>>действительно очень странно — так как использовать заранее созданные делегаты это уже не рефлекшин и сравнивать этот способ с получением значения по именни как то не коректно
O>Вы бы еще более древнюю статью выбрали бы и изумлялись бы, что ж так бедно-то...
упс — чот я не посмотрел на дату статьи
смотрю в топе висит — почитал удивился
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, TATAPuH, Вы писали:
T>>>Режет глаза то, что не хватает самого производительного (ГИПОТЕЗА) после директа варианта — IL-генерации. T>>>Рассказываю людям, а они делают круглые глаза, мол, это как это так ?!
TAT>>действительно очень странно — так как использовать заранее созданные делегаты это уже не рефлекшин и сравнивать этот способ с получением значения по именни как то не коректно
O>Вы бы еще более древнюю статью выбрали бы и изумлялись бы, что ж так бедно-то...
