Как стать автором
Обновить
29
Карма
0
Рейтинг

Пользователь

  • Подписчики 41
  • Подписки 3

typeof(T) vs. TypeOf⟨T⟩

Вот вы собственноручно сравните скорость доступа к закэшированным данным в словаре (даже минимально заполненом, 1- 5 записей) и в случае статического дженерик класса с рид-онли переменной, а потом делайте вывод, занимаюсь я ерундой или ещё чем.

И заодно подумайте, почему
EqualityComparer<T>.Default.Equals(a, b);

реализован таким «ужасным» паттерном, а не хотя бы
EqualityComparer.GetDefault<T>().Equals(a, b);

typeof(T) vs. TypeOf⟨T⟩

Вот только замеров не видно и сравнения со статической версией.

typeof(T) vs. TypeOf⟨T⟩

private static readonly bool _value = ValueGetter();

static void AnyMethod<T>()
{
    ... = _value;
}

Возможно, я двусмысленно уточнил, но _value должно быть не общим значеним для любых T, а для каждого T конкретным. Под «достаточно одного T» имелось в виду, что у метода один дженерик параметр, а различных значений T пусть будет от 10 до 100.

Количество обращений более 100. Стоимость значения, как у typeof(T).Name/Assembly/IsValueType.

typeof(T) vs. TypeOf⟨T⟩

Чтобы уж точно не было разночтений по стоимости создания, можете просто взять за эталон работу с типами из публикации typeof(T).Name/Assembly/IsValueType.

Нужно сделать быстрее в два раза при множественных вызовах.

typeof(T) vs. TypeOf⟨T⟩

Зачем? Это единственно верная формулировка задачи?
В статье и примерах кода, которые вы так дерзко критикуете, решается по сути именно такая задача — закэшировать данные, зависящие от дженерик параметра, для последующего максимально быстрого доступа. Вы утверждаете, что код ужасен, тогда предложите правильное решение…

Критерии:
— минимальное время выполнения при многократных вызовах
— серьёзных ограничений по памяти нет, потребление в переделах разумного
— чтение многопоточное
— достаточно одного T
— кэшируемое значение любое (для простоты bool, string, object)
— стоимость создания определяется так: если кэшированный доступ даёт выигрыш по производительности в 2 и более раза в сравнении с созданием, то задача решена
— желательно ещё, чтобы это было справедливо для любой CLR (.NET Framework, .NET Core, Mono).

typeof(T) vs. TypeOf⟨T⟩

… а это удобно? Никогда бы не подумал. И код, который вы приводите, традиционно плох. Даже нет, не плох — ужасен.
Да? Тогда задачка для вас: закэшируйте значение в статическом дженерик методе AnyPerformanceCriticalMethod⟨T⟩(), зависящее от параметра T, это же просто, верно? Мне очень интересно увидеть ваше более оптимальное по производительности решение, потому что лучшего я не знаю, а хуже да, могу предложить.

В таком случае заодно можно считать, что этим статьям не место на хабре, потому что мне хочется думать, что аудитория здесь не состоит из «таких же тугодумов».
Вам, может, и хочется так думать, но своих читателей на Хабре публикации находят.

typeof(T) vs. TypeOf⟨T⟩

Для проведения дополнительных тестов открыты все исходные коды. Можно модифицировать их по своему усмотрению и проверять различные интересующие сценарии.

Так что любой товарищ, участвующий в споре или наблюдающий за ним со стороны, может их провести.

typeof(T) vs. TypeOf⟨T⟩

Здорово, а я вот лет 7 пользовался дженериками и только на седьмом году чётко понял, что кэшировать переменную в дженерик-методе удобно через статический дженерик класс.

class Cache<T>
{
    public object Instance { get; }
}

static void AnyMethod<T>()
{
    var anyInstance = Cache<T>.Value ?? 
    Cache<T>.Value = ReadOrCreate<T>();
}

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

Возможно, вы уже ушли далеко вперёд в своём профессиональном развитии и для вас все эти замеры выглядят бессмысленно, но со скромных высот моих познаний смысл в них всё же есть.

typeof(T) vs. TypeOf⟨T⟩

Извините, конечно, но в дженерик случае через статических класс — это не настолько очевидно, как в обычном. Вы сами-то применяли осознанно такое решение раньше? А если применяли, то на каком году программирования дошли?

… и о чем же?
Оставляю на ваш суд.

Про чайник теперь услышал.

typeof(T) vs. TypeOf⟨T⟩

Но у меня не получилось воспроизвести ситуацию с недоинициализацией…

using System;
using System.Threading;
using static System.Console;

namespace Ace.Base.Console
{
	class MyClass
	{
		public static MyClass Instance;

		private MyClass() => Thread.Sleep(5000);

		public static void AsyncInit() => new Thread(() =>
		{
			WriteLine("Started");
			Instance = new MyClass();
		}).Start();
	}

	static class Program
	{

		static void Main(string[] args)
		{
			try
			{
				MyClass.AsyncInit();
				Thread.Sleep(1000);
				WriteLine("Ready");
				WriteLine(MyClass.Instance?.ToString() ?? "<null>");
			}
			catch (Exception e)
			{
				WriteLine(e);
				ReadKey(true);
			}
		}
	}
}

typeof(T) vs. TypeOf⟨T⟩

Серьёзно. Это просто, но не очевидно.

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

typeof(T) vs. TypeOf⟨T⟩

Спасибо, интересный пример, он очень напоминает передачу ссылки вовне из конструктора.
class Tester
{
  BoxedInt2 _box = null;
  public void Set() {
    _box = new BoxedInt2();
  }
  public void Print() {
    var b = _box;
    if (b != null) b.PrintValue();
  }
}

По идее, можно исправить так (если компилятор не соптимизирует)
class Tester
{
  BoxedInt2 _box = null;
  public void Set() {
    var tmp = new BoxedInt2();
    _box = tmp;
  }
  public void Print() {
    var b = _box;
    if (b != null) b.PrintValue();
  }
}

Поскольку вызов конструктора — блокирующая операция.

typeof(T) vs. TypeOf⟨T⟩

Я в комментариях признал, что со словарём у меня ненадёжный код и даже внёс соответствующее примечание в публикацию.

typeof(T) vs. TypeOf⟨T⟩

Какой смысл в результатах (неправильно проведенного эксперимента) без анализа?
Смысл такой — есть способы ускорения множественных рефлексивных вызовов на основе кэширования результатов, они представлены в статье, и если вы на практике столкнётесь с подобными сценариями, то сразу будете знать куда копать в целях оптимизации.

Кстати, а как же вы делаете выводы (которые в вашей статье есть) без анализа? Просто «что придумывалось»?
Выводы не выходят за рамки ответа на ваш предыдущий вопрос «в чём смысл?».

Ну то есть вы вывалили нам какие-то результаты, полученные неизвестно из чего, и даже не знаете, что они означают. Круто.
Раз вы так уверены в моём невежестве, то могли бы сами и пояснить, что они означают…

typeof(T) vs. TypeOf⟨T⟩

В этой статье я не занимаюсь анализом, а всего лишь, как сказано ранее, выдвигаю гипотезу, провожу эксперименты и делюсь результатами — в этом моя цель.

И одна из причин, почему не углубляюсь в анализ, это те дикие дебри, которые лежат за полученными данными, почему они именно такие…

И да, в наработках много экспериментальных идей, которые со временем могут выбраковываться из-за их несостоятельности, это вполне нормальный процесс. Есть и такие, что остаются.

typeof(T) vs. TypeOf⟨T⟩

С удовольствием ознакомлюсь с результатами, если вы этим займётесь и поделитесь с остальными. :)

typeof(T) vs. TypeOf⟨T⟩

Скажу прямо — если бы кто-то мне платил за то время и силы, что я трачу на статьи, то можно было бы говорить о разжёвывании материала, подробном анализе и детальном рассмотрении всех возможных аспектов.

Сейчас я делаю это as is — указываю на ключевые моменты и идеи, предоставляю примеры, а читатель уже сам решит, что и как ему с этим делать. Я ничего не продаю и не рекламирую, если и публикую ссылки на код, то лишь делюсь личными наработками с другими людьми, и да, иногда кто-то находит там для себя что-то интересное.

typeof(T) vs. TypeOf⟨T⟩

Судя по количеству добавлений публикации в закладки, кто-то всё же считает информацию пусть даже потенциально, но полезной.

typeof(T) vs. TypeOf⟨T⟩

А другую половину можно.

typeof(T) vs. TypeOf⟨T⟩

Ну да, а публикации на хабре они недостойны, дадада.
Достойны, но вы ж должны понимать, что статьи я пишу лишь в своё свободное время for free. Подготовка материалов даже к этой публикации потребовала уйму времени и сил. Да и пишу в основном о том, с чем сам сталкиваюсь на практике. Нужно или не нужно, люди сами уже для себя решат.

На вопрос почему разные CLR генерируют отличающийся код, исчерпывающего ответа не нашёл и в оригинальной дискуссии его тоже не оставили.

Информация

В рейтинге
4,394-й
Зарегистрирован
Активность