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 генерируют отличающийся код, исчерпывающего ответа не нашёл и в оригинальной дискуссии его тоже не оставили.

typeof(T) vs. TypeOf⟨T⟩

Вы сравниваете решение, которое корректно работает всегда, с решением, которое работает иногда, и никак это не оговариваете. Некрасиво.

Данная некорректность обнаружилась уже в ходе обсуждения, и я сразу сделал честное примечание в тексте статьи, что лучше использовать более надёжное решение в плане потокобезопасности.

Чтобы уж не было никаких сомнений, укажу, что это может повлиять на производительность.

typeof(T) vs. TypeOf⟨T⟩

Вообще-то определил, но, к сожалению, теперь вы не сможете просмотреть детали в открытом доступе, которые раньше находились тут.

В общих словах, различные CLR генерируют неодинаковый код во время JIT-компиляции при доступе к статическим рид-онли полям классов (некоторые добавляют дополнительную проверку на то, проинициализировано ли поле, что сказывается на производительности). Тема также тесно связана с добавлением статических конструкторов, у которых, как оказывается, есть ряд подводных камней…

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

typeof(T) vs. TypeOf⟨T⟩

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

typeof(T) vs. TypeOf⟨T⟩

Извините, но за детализацией отправлю вас к публикации, где чётко прописаны все исследуемые сценарии.

typeof(T) vs. TypeOf⟨T⟩

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

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

typeof(T) vs. TypeOf⟨T⟩

Что-то этой проверки не видно в посте.

Вы же мне помогали в комментариях совместно с другими людьми проверять некоторые мои допущения о словаре и блокировках. Основа поста — идеи для реализации TypeOf и RipeType, а моя имплементация вполне может иметь недостатки, и я очень рад, что мне на них указали.

Как мы уже неоднократно наблюдали (и обсуждали), у вас очень удобное для вас понимание убедительных аргументов.

Я и говорю: вы выбираете то, что вам хочется. Правильность или ее отсутствие вас не волнуют.

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

typeof(T) vs. TypeOf⟨T⟩

Я от этого далеко и не отхожу:

1. изучена работа typeof и Type
2. выдвинута чёткая гипотеза, что TypeOf и RipeType могут работать быстрее в некоторых сценариях
3. разработан и проведён ряд повторяемых экспериментов, в том числе опровергающих гипотезу

Получены результаты и предоставлены на рассмотрение широкому сообществу. :)

typeof(T) vs. TypeOf⟨T⟩

Я дискутирую, а не доказываю и, как видите, при наличии убедительных аргументов, готов признавать свои ошибки.

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

Во-вторых, некоторые подозрительные места я замечаю и мне наоборот весьма интересно провеить их в нестандартных условиях.

Для меня подобные публикации что-то вроде код-ревью от сообщества, с чем-то соглашаюсь, с чем-то нет.

typeof(T) vs. TypeOf⟨T⟩

Кстати, ваш словарь еще и публичный, поэтому все и любые утверждения про то, что модификация только под локом, невалидны.

Спасибо, в коде я это уже подправил, а в статье осталась неточность, подкорректирую.

Вот только вы можете получить true и null.

Может быть, и могу. Но дело в том, что у меня такая позиция в программировании — испытывать на прочность самые неожиданные сценарии и варианты, а не ходить по проторенным и безопасным тропинкам. :)

Конечно, в коммерческих рабочих проектах я обычно применяю более надёжные решения, но в своих исследовательских ни в чём таком себя не сдерживаю.

typeof(T) vs. TypeOf⟨T⟩

Да, потенциально (хотя не стопроцентный факт, но для меня убедительный) это место может упасть с ArgumentOutOfRangeException из-за возможной гонки при присваивании в две переменные, как упомянул в комментариях retran.

typeof(T) vs. TypeOf⟨T⟩

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

typeof(T) vs. TypeOf⟨T⟩

Кстати, про syncroot на коллекциях вы не знаете, да?

Знаю, но в некоторых случаях мне хотелось бы абстрагироваться от введения явной переменной, отчего и появился

public static class Lock
{
	public static TResult Invoke<TSyncContext, TResult>(Func<TResult> func)
	{
		lock (func) return func();
	}
}

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

Потенциально возвращенный null вы тоже обрабатываете? Что-то не видно.

Обрабатывается потенциально возвращённый false. :)