Обломный preview, правильные списки, спасительный кэш

Здравствуйте дорогие друзья, в эфирии RadioDotNet, летний выпуск 97-й в эфире в жарких студий Анатоль Калаков и играл оботин всем привет. Спасибо вам за помощь всем, кто шарит, репостит, комментирует наш выпуск, а именно нашим блестящим помогатрам, которые не

оставляют на усадних набусти среди них. Александр Сергей Владислав Шевченко Антон, Лазеревый Лья, Гури Самарин, Виктор, Руслан Нартамон, Александр Ирией, Идин Сергей Безенко, Александр Лапеднин, Ольга Бандаренко, Дмитрий Сорокин, Сергей Краснов, Константин Ушаков, Андрей Фозлеев, Босимоль Джевахири, Андрей Маслов. Я всем большое спасибо, кто нас поддерживает, а также всех тех, кто, пожалуй, остаться неизвестными. И заходите к нам на Бусти и посмотрите, что там

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

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

много, много, много, много, много, а по факту, что-то как-то оказалось важного, не так-то и много. Но давайте пробежим все по порядку. Начнем с библиотек. В библиотеках там какой-то прям огромный упор на пакет под названием System No Mirax. Напомню, это пакет, в котором лежат всяческая, на имспейс, на котором лежат всяческие разные типы, относящиеся к математике. Там лежит бегинтоджер, там лежит вектаризация всякая. И вот как раз такие в бегинтоджере ограничили количество символов цифр,

точнее, если быть более точным битов. Ты знал, что у бегинджинджи раньше не было лимита? Да, я всегда наделся, что он бесконечный. Теперь он не бесконечный, теперь у него есть верхний лимит, ты ему не можешь туда запихать больше, чем 2 миллиарда битов. Так что же забеспредел? Что это такое? Собестимые скрекуляторами что ли? Ну, а как они сказали, что в именно таких объемах, как бы стандартный, дотнетный бегинтоджер, ведь это вся плюс минус, нормально, а если вам нужно больше,

но вам явно что-то нужно костомное, лучше напишите костомное и используйте наш. Теперь работать не будет. Дальше добавили опи под названием Big Mull, ну, смысле, Big Multiplication. И это, наверное, как это, ну не то, чтобы отменить, но по крайней мере, повлияет на часть вопросов на собесенования, когда спрашивают, как нужно умножать Интноинт с учетом переполнения, вот это все,

да, что будет, когда их умно уйдать. Короче, теперь есть описька, которая принимает 2-й табы, возвращает лонг, или который принимает 2 лонга и возвращает Инт-128, ну и так далее. Так, если вы тярв на жайте, вот можно это делать теперь безопасно, это и штукой. Да,

хорошая ответа, главное его как бы запомнить и узнать, с какой версией он доступен. Также появилось некоторые конвершен и пи из для векторов, то есть если вы хотите сконвертировать, например, конь, ведь там не знаю, вектор размера 3 или 4 в квадрнион, что тоже является, по сути, вектором размера 4, то это теперь будет 0,1 оперation, ну то есть это не будет требовать никакой хеориальной конвертации, он просто это скастует объект 1 к 1, структурук, ну будет считать другим типом, все будет хорошо.

Ну и появилось создание опи же, мне казалось, что раньше было вектор Кэйд и Пи из для вектор Т, вектор 2, вектор 3, вектор 4, но вот сказали, что чут новые добавили, ну добавили, добавили, я как-то векторизация не занимаюсь, поэтому не знаю, что там происходит. Дальше из библиотек, следующий кусочек это штука под названием поддержка праймери конструкторов в Login Source генераторе, то есть если вы берете класс, в этом классе объявляете праймери конструктор и у него есть

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

Фистин текст json не появился, довольно много штуков, а теперь есть json схем и в спортор, она позволяет заэкспортировать json схему для дотнет типа, вероятно эта штука была нужна для какой-нибудь опыно-пигенератора или что-то подобного, и поэтому теперь она есть в виде вукличного типа, то есть у json схем и в спортера есть такой класс, если теперь метод, который называется get json схем snote, которая возвращается обстанно, ну, описание json, по задному типу, можно цель так?

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

вот, видимо, для этого и нужно. Систем txjson, интересный заголовок, я сначала даже поставил в тупик, называется respecting nullable annotation, то есть раньше система txjson вообще не смотрел на nullable annotation, теперь смотрит, и теперь он может быть конфигурен для того, чтобы это дело

enforсить, эти самые антейшн, для этого нужно включить флаг respect nullable annotations, и который по умолчанию выключен, да, да, да, да, да, да, да, да, и либо можно его включить через фича свич, через ваши имя с билдовые пропертией, под названием

sysxjson, json serialization option, respect nullable annotation, с той и так далее, он начнет учитывать самый nullable annotation, если у вас есть nullable типы, в jsonчике нет у какого-то поля соответствующему эту типу, ну проперти с этим типом, то это будет ошибка десерализации,

да, и туда же поддержка nullable constructor parameters, то есть раньше если у вас есть параметр конструктора, которые являются фактически обязательными, ну например, это ваш единственный primary constructor, да, и он антилизирует как и не то он ли свойство, то есть если вы не зададите

такой параметр в конструкторе, и вы, по сути, обег не можете создать, раньше это дело и гнорелось, вот теперь все это нормально, можно опять же включить, называется respect recoise, конструктор параметр слаг, тоже можно включить через фича свич, вот ну и при этом вы можете менять, как они называются requiredness, то есть свойство обязательности поля через отдельный атрибутик на свойстве, да, json пропers info.exe и зря квает, то есть короче явно потихонечку причёсовую, причёсовую, я бы сказал, а

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

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

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

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

ну а 100% покрытие авто тестами, что-то так не делаешь разы, ну да, ладно, дальше, в JSON-обжекте это объект, ну классно, который позволяет вам работать с произвольным JSON-ом в то-3 появилась поддержка последовательности порядка свойств, то есть вы, несмотря на то, что в целом,

ну в отличие от XML, JSON не то, что обычно рассчитывают, да, что свойств ведут в определенном порядке, так и более того, JSON на самом деле нет никаких свойств, потому что объекты со свойствами описываются синтеги сам дикшенери, то есть на самом деле это дикшенери, а у дикшенери как известно ключи,

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

JavaScript криптиями с нами, то для один из плагинов Нжникс, на JavaScript криптий, не подден, как раз считал, что и надо поддерживать порядок свойств и там аксортировал в произвольном порядке, вот, в принципе он прав, но все сказали, ну ребят, как бы, все браузеры работают с учетом порядкой,

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

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

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

Джооскрептантайме, который использовал EngineX, там была какая-то старенька версия, он как бы выдавал рандомный порядок, потому что операция сортировки как бы работала, но при записи обратно Джейсон обжиг, никто не гарантировал порядок, ну вот использовали листы, листы гарантировки,

да, да, да, да, да, все так, ну там не на Сишарпе, нужно было это все это еще бронутся такими более объемистые Джейсон объекты, поэтому пришлось немножко поплатить, ну нормально, сработало все таки, и последнее что добавили про Систан текст Джейсон, это называется

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

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

появились паршел-проперти, и, соответственно, тут же разрешили в.нете библиотеках Джейсон Рейт от Регекс от ребут на пропертиах, то есть теперь не обязательно прям класс, метод точнее задавать, можно сделать, проперти, и в Регекс это добавилось еще одна важная

штука, называется и номер Айт Сп лиц, ну, всем, наверное, известна штуку, под названием Stringsplit, это функция, да, метод, которая позволяет взять строчку, разделить ее по задному разделителю и получить вот этот массив строчек, все с ней хорошо, все замечательно, но она

делит только по фиксированному количеству, но по фиксированным строкам, понятное дело, есть соответствующий аналог, это Регекс точка сп лиц, который позволяет взять строку, разделить по какому-то задному Регексу на кусочки, и вернуть с адрес на массив строк, но

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

называется и номер Айт Сп лиц, который, во-первых, принимает спаны, а не только строчки, во-вторых, он возвращает и номер обл из RNG, то есть рэнджет, напомню, такая структура, которая, по сути, просто указательный начало, указательный, ну вот, вот, вот, вот, вот, вот, вот, вот, вот,

в виндекс, начало, в виндекс конца, в оригинальном спании, по сути, и теперь вы можете ничего не олацерва делать Регекс Сп лиц, то есть по Регексу сплить ваши строчки, без каких-то накладных расходов, особенно если учитывать что Регекс умеют в сурсгенерированные версию,

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

Так, привекексы все, про Order Dictionary я уже сказал, это новая коллекция, которая позволяет использовать в отличие от Dictionary, который не гарантирует порядок, к лучей коллекции, Order Dictionary, соответственно, позволяет это делать в принципе такая коллекция была уже

в дотнете давно, но она была не джинариковая, а поскольку мы сейчас все боремся за всякие ммр и прочее, видимо, она где-то потребовалась джинариковерс, и вот ее добавили, теперь она ездит на рекверсии, а еще джинариковерсии привил из штука под названием Redone Leset, у нас уже был

пла коллекция под названием Redone Recollection, это по сути в Rapper, да, на любом более-менее или с том отт, но только делающий в Redone ли вариант, есть Redone Les Dictionary, по сути то же самое, только на обычном дикшенере, но для сетов ничего такого не было, теперь есть Redone Lesets,

то есть на штука, которая позволяет обернуть любое Iced в коллекцию, которая будет только отлично и будет позволять себе именять, так дальше про конструкции мы поговорим в секции про 3, 6 шарп 13, коллекшен Лукап в это спанс, это такая очень очередная, мне кажется, очень

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

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

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

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

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

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

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

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

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

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

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

рум-код, у нас есть универсальный методокодирования чего-то у рум в этот самый фюрл, ну, с понятным, с escapeingом, поэтому я обычно не обходился в b64, что-то не надо было, ну ладно, так кажется, что немножко не было, потому что у рум-код, ты помбай-то передать не можешь,

ты можешь только строчки передать, а это что-то прям массив бай-то, да, и что, если любый бинарь может загнать в такой формат, и это бывает часто удобно, и за последние М не подоговорить сать, не было ни надо ни разу, честно говоря, вот бинарь в b64 запихать,

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

много, раз меньше, но не вам много, не вам много, они раз меньше, там все он 128 бит, который все равно нужно как-то упаковать, там все равно меньше, ну как, ты там 16 речный система, а здесь 64 речный система, есть речность, да, ну, ну, как бы не вам много,

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

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

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

Дальше поменялось, вот это может быть как-то более будет важно. Я, честно говоря, не смотрел какие-то выкладки по-перфомансу, с точки зрения там, какие-нибудь много процентов оно приносит, во-второжно, потому что доли процента не знаю, в Татине было. Это расположение кода. То есть при компиляции, когда метод компелировается, джитом уже понятное дело не в момент компиляции компилятор.

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

Ну, в смысле, раскладывать в правильную максимально предсказуемую последность, в том смысле, что угадать на сколько максимальной вероятности того, что именно так пойдет выполнение кода. Ну, или большим количеством случаев. И вот теперь он стал использовать информацию у профалинки. То есть раньше он не использовал информацию PG-A, про это дело про файл-кайдер-три-мизаишин, а только, ну, какие-то свои внутренние вристики теперь это используют.

Еще какие-то вристики добавились и утверждаются, что раскладка теперь, прям, если не идеально, то гораздо лучше. Кот должен работать быстрее и с меньшим количеством переходов. Оптимизация циклов еще один вопрос, если разряда, а теперь это не актуально на записедываниях, может быть, слышал, да и может, и сам спрашивал, не знаю, в докладах точно это встречалось, про то, что если ты пишешь цикл от 0 до 10, это может быть медленнее, чем цикла 10 до 0. Да, да, было дело.

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

Что-то уже страшно, как бы становится. Ну вот, да, будем считать в другую сторону, и все автоматически. Не знаю, как определяет, что это безопасно, но как-то определяет. Я бы еще поверил, что рослин может определить. Ну, у него как бы больше информации, да, а на уровне джитта понять, что вот этот вот цикл. То есть либо это даже не менее, чем простые циклы. Ну, там не знаю. Типа сумма средней, чем-нибудь такое.

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

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

А ВX10 вы один сапор, то тех, кто знает, что КВА-X и штука ВА-X10, наверное, порадуется новой набор, или, так понимаю, инструкции векторизации, поддержанная от Intel. Так, к кода генерация для интрии-сиков, она, в принципе, и так была, просто еще больше расширяющая, в когда она чуть лучше работает.

Ну, и вот так говоришь, должны отключаться, как когда в Floating Point ты видишь, но нет, как раз появилось, что-то под названием Constant Folding, да, сворачивание Constant, для Floating Point и 7. То есть сам понимает, что ты замерзнай вектор на прибавляешь 0, то он это сделает нопом и не будет ничего делать. Такое. Ну, для константы ладно, константы еще можно как-то поверить? Да, так, SDK. Моя потихоньку ближе к концу, не так много уже осталось.

SDK это несколько вещей поменялось, в основном связанных с аудитом и с сборкой. Значит, с аудитом. Мы уже рассказывали про штуку под названием Nokia Toad Hit. Помогите, в прошлый раз ли? Нет, не, в прошлый раз, кстати, были в поза прошлая разная. Мы рассказывали про Nokia Toad Hit. Это что, ну, новое как бы. Решим работать, так скажем, не знаю, или кусочек. Система сборки, кусесема SDK, ресторопокет, в которой позволяет проверить все покеты на уязвивости известной.

По default она работала раньше только для прямых зависимости. То есть она проверяла прямые зависимости, что не проверяла транзитивные. Теперь, соответственно, обменился default, теперь она будет проверять и прямые и транзитивные. Но можно обратно вернуть только прямые и поставить правильную пропертиру нog это аудитомолт. Нужное значение. Появилась новая команда.

Заваяться DotNet, Nuget Y. Когда я занимался проблемами, которые это команда, призвана решить, мне бы, наверное, правильно казалось, что она должна называться DotNet Nuget VTF. Но пусть будет Y. Она позволяет нарез... То есть вы изотаете название DLL или Пакета, который вы видите, грубо говоря, у себя в отпути, а она вам пишет откуда он взялся из-за каких-то транзитивной зависимости. Да, очень мегаполизмная команда.

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

А здесь вот тебе, по сути, я так понимаю, вот тут грубо говоря, поэтому дерево ищет короткий путь корню, да, задны, вот, ну, в принципе, то есть такой реализации, скорее всего, халявное, а пользы на самом деле много. И последний штука называется MSBilt.Bilt.Chex. Короче, росли нам мало. У нас теперь будет новые анализаторы на уровне MSBilt. Называется это Bilt.Chex. И помню, у меня Microsoft они призваны заинфорсить еще больше правил, всяких инвариантов, именно во время билдов.

И цель не только, как бы, ну, уломать фэшбилд, да? Ну, и давайте какие-то подсказки, ну, возможно, как-то что-то, где-то говорить не просто, что вот бил слово, но вот вот потому-то и потому-то. Пока добавлено всего два билд, Чека, билд, Чек номер один. Это нельзя делать, Шерт, аутпутпат, если у вас в солюшине есть как-то проектов. И у них у всех аутпут или интермития, то он указывает, ну, не у всех, хотя бы у двоих. На одну и ту же директорию, это будет ворненько время билдам.

Номер Bc 01 01. И, соответственно, второй ворненько это, если МСПилд за дитектор, что вы один и тот же файл, по какой-либо причине, не важно, по какой-то затираете два раза, ну, здесь затираете, пишите в смысле в него два раза, то это тоже будет ворненько, давайте довольно ради дитекшен. То есть, в принципе, это обычно неправильно, если файл, и должен писать, вовремя билда, один раз. Если вдруг он будет... Это руслинный анализат или для МСПилд?

Ну, типа того, да, ну, только что без фиксеров автоматических, да, потому что... Это пока, наверное.

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

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

Вот такая вот штука у нас в СДК появилась, посмотрим... Ну, да, да, давайте. Хороший флажок. Насколько, но ты уже перешел на 9 СДК? Нет, ну, я надеюсь, что флажок не добавит, никто не мешает, или он начнёт того, что-то может быть вылетен. А, кстати, интересно, ты же здесь ведь там можешь передать. А я не знаю, кстати, я не помню, честно говоря, рукается или МСБилд на неизвестные муфлажки. Так его, знаете, кстати, не пробовал. Вот, не передавал. Ладно, давай дальше.

Последний кусочек, это АСПенадкор. Там, соответственно, добавились фингер-притинг статических ассетов. По-моему, я про это уже где-то рассказывал, мне кажется, или что-то они добавляли уже, а они добавляли коширы у ней изивования, добавили ещё фингер-притинг. Соответственно, теперь они добавляют уникальный hash-contenta к файлным. То есть, если у вас лежит какой-нибудь, не знаю, ЦС-сник или JS-файлик в статике, то в изборке он переименуется, и в этот файлик допишется его чексума, грубо говоря.

Ну, hash. Поскольку во многих местах он нужно ссылаться на этот файлик по имена, но, как бы там, есть дальше некоторые моменты, как это сделать. В БЛА-йзаре всё включено по умолчанию, для MVC и для Razer pages нужно включать это через использование. Вы должны использовать мэп-статик-эссетс, вместо U в статик-файлс, ну и все-таки, ещё позвать метод with статик-эссетс. В БЛА-йзаре, соответственно, дальше нужно использовать пропиртул-эссетс в компонент-бейзе для того, чтобы добраться то нужного.

Файлика, и там есть индексер, куда вы передаетесь исходными файла, он будет знать, с какой чексумой за ним сходить. В ВСИ-эссер, а из РП-йзже, там все вот эти вот так-хелперы, они подкручены, так что вы ссыладись просто на MVC, а он сам сходит за нужно. Для сигнала развезлить, струбьют от трейсинг, теперь есть отдельный активитель ссор, под названием Microsoft, я спонадкор сигнала, а Арсервер, и он там старается репортить. И венты для всех вызовов, соответственно, хаба, но методов хаба.

В ОПН-EPI появилась некоторая такая, количество изменений, во-первых, я что-то не знаю, по-моему это первый раз, когда такое сделал, я Microsoft со словами, видимо, что, что-то как-то наши, это новые опыные мпиай, не очень дискафер был, сделали такую штуку. Я не знаю, это рослин, это дело-то, кто? Вы теперь, когда вы пишите, нужно вам говорить там, там у тебя вы должны написать Юзы опыные пиай, это же экстанжен метод, да?

И теоретически он там должен появиться, и если у вас есть резорефер, то есть на гет-пакет, с этим самым опыные пиай, кусочком. Так вот теперь, в студии по крайней мере, вы можете писать, сначала писать Юз, и он вам подскажет, что можно написать Юзы опыные пиай, хотя вы еще пакет не зареференесили.

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

Да, да, да, да, сейчас мы в студии покорим, в конце выпуска там будет немножко про это. Дальше, если вы на параметрах ваших, ну, в смысле, на параметрах методы, либо на пропертеах ваших деталошек, используете атрибута, рекуарты или итифолт-велью, они садыстно будут переделаны в Open API схему, когда Open API схеме генерится. И еще добавлю, что купод названием схема Transformers. То есть, после того, как вы, просто как автоматик из генерит, вам JSON схему в Open API.

Open API, JSON схему в вашу IP, можно еще зарегистрировать нужное количество Transformers, но через функционный API Options, которые позволяют ее потом подредактировать на лету. Чуть не добавить, чуть расширить, например, в примере, ну там, тупая примера, они просто дописывают какой-то там, что типа автора и description. Общий description на всю схему. Ну, ну, возможно, вам сделать что-то более экзотическое, если надо.

И последнее, что добавили, это Analyzer, который проверяет, как вы используете атрибуты Authorize и Allow Ananimus на ваших контроллеров, методых, и так далее. Потому что есть такая штука, что если вы используете, например, контроллерия Authorize, она методи использовать. И Лао Анонимус, то все хорошо. Все методы контрольера будут требовать в тряпоте в трязации, кроме того, методокатуры, помечен, как И Лао Анонимус.

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

Ну вот как есть, как есть. Но я специально опустил всё про Сешироп-13, про него у нас отдельная статья. На там тоже не так много, прям скажем. Давай, не это самое, чтобы Сешироп-13 ты пока отдохни, а мы немножко тогда обсудим, что у нас не то, чтобы новенького, но старенького есть. В наших фремворках мы же не только на вас на подкастной все образовательны, будем образоваться на тем, что уже есть. Хочется с вами поговорить про неизменяемые коллекции, которые нас уже существуют в Доднете.

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

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

Вот давайте посмотрим, что вот в Доднете для этого есть. Мы, естественно, не будем рассматривать все неизменяемые структур данных, мы становимся на несколько самых популярных. В частности, мы про анализируем, чем отличается друг от друга Редонле структур данных, им Ютубал и Фрозен. Вот некоторые у нас появились довольно давно, так и как Редонле и Мьюдобльный появились немножко позже, а Фрозен это вообще свежака может быть не каждый разработчик еще с ними спил поработать.

Ну, тем полезнее будет это статья, о котором мы с вами сегодня поговорим. Так, прежде всего. Давайте начнем с Редонле. Ну, все вы можете представить какой-нибудь лист, который мы можем сложить кучу каких-то рентов и создать его. Я думаю, каждый день любой разработчик, такие листы создают с какими-нибудь содержимым. Как нам из обычного листа получить Редонле лист? Все очень просто нужно вызвать метод Ас Редонле. И он нам вернет специальную Редонле лист.

Тот объект, который нам вернет, на самом деле является всего лишь на всего проекции оригинальной коллекции, оригинального листа. Что это значит? Что, если мы в оригинальный лист добавим какой-то элемент, то в проекции мы этот элемент также увидим. То есть, несмотря на то, что мы владеем каким-то Редонле листом, этот Редонле лист у нас может поменяться. У нас, например, как у какого-то метода. И в этом есть очень большое заблуждение многих разработчиков.

Многие разработчики, когда в методе получают Ай Редонле лист, какой-нибудь ли Ай Редонле коллекшн или Ай Редонле Дикшн. Они считают, что это тот лист, который никогда не поменяется. Это не так. Это тот лист, который вы никогда не можете поменять как метод. Но тот человек, или тот оператор, тот кусок кода, который владеет оригинальным листом, из которого он был построен. Легко может изменить содержимое вашего Редонле листа. Вот, это нужно иметь в виду.

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

Редо сами вы его поменять не можете поменять, может только тот, кто обладает источником оригинальной коллекцией, с которого он был построен. Это самый старый, наверное, способ использовать не изменяемые структуры у нас в заднете. В общем, а там, по-позже появилась такая прекрасная штука, как им YouTube-бл. Наверное, самый главный использователь им YouTube-бл. Это была рослин-команда, и именно она выделила отдельную библиотеку.

С им Юдубл с туктурами именно она пополезавала это подход в Сишар, именно в других языках, естественно, это функциональных особенно. Это все и так было уже на гора. Для того, чтобы из обычного листа получить им YouTube-бл. лист достаточно вызвать метро шириня, то им YouTube-бл. лист, как непродакциально. Это штука создает там тоже некую структуру, которая очень хорошо подходит для потока безопасных модификаций.

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

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

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

Что это значит? Что как бы вы сильно не изменяли лист оригинал, из которого мы породились, им Юдубл лист никак не пострадает. Он никаким образом не изменится. Вообще он никогда не меняется после того как был создан. Несмотря на то, что методы, например, Ed, ремул, вклир и противимодификационные методы у него есть. Но на самом деле, если вы ухоть раз создали, он не поменяется. Это достигается с помощью нехитра магии.

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

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

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

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

На самом деле мы просто ссылочку копируем на старой дерево и всё. Поэтому у имьюуты были на структур, создание копии и модификация происходит очень-очень быстро. Но так как под капотом там используется сложная дерева, медленно происходит чтение, операция чтение у имьюуты были на структур. Как это решить, мы посмотрим дальше. А прежде перед этим хотелось бы минутка истории.

А вэль дерева, которая как раз используется для расшаривания данных в имьюуты были на структурах данных. Что это такое? Да, чуть поподробнее. Это сел в балансинг бинер-ресёр 4. Так, как это можно? Сама балансируемая двоичная дерево-поиска. Интересно на тем, что было изобретено советскими ученами, Георгия Максимовича Максимовича Мадельсон Вельским и Евгения Михайловича Малодис. Очень популярные ученые в математике, физики и в компьютер-санте. А публиковали они в ППС этой структуре 1962 году.

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

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

В общем, если мы такой фокус провернем, то мы увидим, что на х сети это примерно занимает 94 секунды, а на мью-табел сети 4 секунды. То есть вы можете понять, что на самом деле, насколько имгютабель могут быстро создаваться и копировать внутри себя данные. На самом деле переспользовать. В общем, вот этот дерево как раз дает то, что мы экономим 95% всего первоманца,

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

Зачем нам нужны фроузам коллекции? Да и вообще, что это такое? Чтобы получить фроузам коллекцию, ну достаточно на обычном листе, вызак метод Туфроузам сет. Да, нужно сразу поменуть, что никакого фроузам листания существуют. Бывает фроузам сет и фроузам дикшенери. Зачем эти штуки появились? Но прежде всего, насколько я вам раньше сказал, что имгютабельные коллекции очень хорошо умеют модифицироваться, создаваться очень быстро, но из них очень медленно читается.

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

И вот эти структур данных находятся в немспеке, которая называется system collection frozen. И были первые впервые видены в донет 8, поэтому если вы их их ищете где-то раньше, то не рассчитывать. Не найдете. Их остальной концепции заключается в том, что мы можем потратить больше времени на создание этой структуры, но при этом мы заплатим тем.

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

Давайте примерно прикинем, а вот обычные дикшные, если мы возьмем, например, и начнем из него читать. И, конечно, сколько это быстро. Давайте напишем benchmark и сравним это с другими нашими дикшинарями, которые уже есть. Опять же, берем 10 000 элементов и по этим 10 000 элементам, по всем, начинаем читать. Если мы читаем обычные дикшины, то это примерно занимает 46 на на секунд. Если мы возьмем наш им ютабурнен дикшинарей и начнем читать из него, то это занимает уже 388 на на секунд.

То есть разница с обычным дикшиной довольно-то счастлива, как раз потому, что мы идем читать не просто в какие-то массивы слукапами, хэшэй. А лазим по полноценному бинарному дереву. И вымюты будут дикшины в этом плане довольно медленный. А вот если мы все это сохраним frozen дикшинарей, то мы получаем 25 на на секунд на читение. Я напомню, что обычного дикшина рято 46 на на секунд было. То есть это примерно в два раза быстрее, чем обычные дожить дикшинарей.

Какой же магии эта штука может добиваться таких интересных оптимизаций? Казалось, что обычный наш дикшинарей, если кто-то лазил внутрь или задавал собеседования и экспораживали как устроен дикшинарей, он должен понимать, что дикшинарей это довольно прямая, быстрая, а не менее, мегаптимизирована структура. Там всего лишь на всего как бы надо заглянуть в массивчики и все. Как можно ускорить дикшинарей в два раза на пустом месте?

На самом деле очень сложно. И в методику ToFrozen set например, или ToFrozen Dictionary происходит очень много магии и анализа. Техданных, которые содержатся внутри оригинального источника. На основании этого анализа выбирается оптимальный алгоритм имплементатера. То есть, сделав два раза ToFrozen set на разных данных, вы в итоге получите, можете получить, где по абсолютно две разных структуры данных, которые оптимизированы под чтение именно того набора, которого им передали.

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

И если у вас в дикшенаре все ключи разные длины, то никакого смысла считать хуши нет. Мы просто просто посчитаем длину ключей и к каждой длине привяжем значение. Таким образом, мы получаем гораздо более эффективный алгоритм поиск элемента. Другой пример. И если мы, например, используем ключи очень одинаковые. Например, у у нас ключах есть item1, item2, item3, item4, item5 и так далее.

То есть строчки с такими названиями с траковыми, то их сравнение этих ключей, на в случае, если у нас будет hash-коли же. И их сравнение будет довольно медлен, потому что мы будем сравнивать слово item у всех, оно будет одинаковым, и только последняя цифрка будет отличаться. Вот эта фрозон сволочь, она умеет в такие случаи понимать. Она отбросит у ключей, тот привекс, который будет повторяться.

То есть, по сути, она возьмет только последнюю цифрку. Один, два, три, четыре, семь, там, пять, шесть, семь, восемь, и так далее. И от этой последней цифрке она будет читать hash, и от этой последней цифрке она с дебудет делать компар. То есть, она выкинет у хышей, то есть, она выкинет у ключей, первоначальный привекс, который повторяется. Но потому что ей для функционирования этот привекс он не нужен. Он не дает никакой полезной оптимизации. Вот, ну, например, можно, может ускорить поиск.

А есть еще esk-based, хыширование и оптимизации, если мы, например, анализирует, смотришься, там только ASC-SIMVAL у находится, то для них применяется так более прямая алгоритма. Она уже неучитывает какие-нибудь локализации и, прочую, яникоды. А еще один интересный пример — это использование case-sensitiv, хыширование на case-sensitiv данных. Как такое вообще возможно?

Вот, допустим, мы создали дикшен, и говорите, что у меня стратегия сравнения — она case-sensitiv, то есть, мы должны сравнивать с учетом, обязательно без учет регистер. Что это значит? Это, по сути, значит, что case-sensitiv, считать от таких структур очень сложно. То есть, вам нужно эти строки, например, эти ключи, там привести в какой-нибудь аперкей, если посчитать case-sensitiv, или еще как-нибудь вымудриться.

То есть, допустим, это не так просто, как сравнивать, допустим, case-sensitiv данных, которых никаких трансформаций делать не нужно. Просто берегаешь еще тай. Ну, и с компаром, то есть, сравнением, даже самые проблемы, даже самые бенефиты. Вот. Если вдруг этот алгоритм обнаруживает, что вы хотите дикшен, или со стратегией, case-sensitiv,

иногда он может понять, что вы на самом деле этого не хотите. Когда это может быть? Например, что несмотря на стратегию, по факту, в дикшенере лежат, допустим, только ключи, состоящие только из-за них цифр. И все. Там нет букв. А раз там только одни цифры, то на case-sensitiv стратегию сравнения можно просто просто забить. И поэтому он специально включает case-sensitiv стратегию. И, естественно, очень сильно возрастает, очень сильно возрастает скорость поиска и чтения из-за этого.

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

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

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

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

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

Ну ладно, придется думать, а пока давай пойдем дальше, дальше у нас тот кусочек, который я обещал, это C-Sharp 13 вышло статья, она не то, чтобы относятся непосредственно к preview, она просто в целом про все апдейты, которые есть C-Sharp 13, тем на текущий момент. На на самом деле мне кажется все-таки не все, мы же по-моему обсуждали, фичу под названием FieldKeyward, когда ты теперь можешь не создавать правят поли.

Да, обсуждали. Ну вот и по-ам скалекши, напочутали, что можно теперь в парамсах использовать всякие там аридонали, а или именно обсуждали по результатам Build-on, но мы этого не видели в реальном preview, вот короче, теперь все это есть, значит давайте по порядку пробежимся, если где-то что-то повторимся, значит повторимся, ну заодно получше запомните, и будем надеть что-то не выкинут из релиза, а то запоминали зря. Итак, значит что у нас есть на текущий момент, точно известно, что

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

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

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

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

принципе даже на любом волью тайпе он забоксится, пользы это никакой, но технические по-моему компилятор не запрещают, теперь у нас есть новый тип, называется system trading clock, видит он свеб пока абсолютно так же, но вудуще есть надежда, что будет здесь все более оптимально, более быстро и планы на то, чтобы со временем сделать его так сказать, основным механизмом работы с локами в будущем Сежарпе, дальше если вы пользуетесь нециализаторами,

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

ну если вы хотите заполнить, например, в таком списке первые последние элементы, в принципе, будет удобно, добавили новый escape sequence, у нас уже есть escape на помни�ки психи, это штуки, которые в строке начинают с бакслаша, там все какие, ну с лошара, с лошен, все знают, вот теперь есть лошьи, это escape sequence, раньше нужно было написать с лошью 0.1B, это его ask-y-kot, на самом деле, практическая польза есть, если вы много работаете стериминалы,

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

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

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

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

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

кище один новый женерик констрейнт, называется elau-s rev-struct, позволяет собственно рев-стактом, наверное, самый известный, это спан, это объекты, то есть, не типа, которые могут быть аэллосированы только на стеке или на, ну, соответственно, не могут храниться в куче, они теперь могут быть констрейнтами в женериках,

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

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

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

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

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

поэтому экстенджен-тайпов в 13 сежар пине будет, ибо и ждите их в первых приведешьках 14 сежарпа, поэтому, ну и зачем они нам нужны в приведешьках, мы их его задать, хотим им они приведивать, ну, иди, они сталкнулись с некоторыми трудностями, либо не знаю, не успевают, либо нашли какие-то проблемы, либо что-то с хемпетой не склеивается,

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

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

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

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

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

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

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

Дальше ваш запрос должен быть дорогим для выполнения, как я уже сказал, это дорогость, то насколько он дорок может зависеть много чего, там может быть, CPU, memory, все эти что угодно, но его должно быть дорого выполнять. И результат должен быть стабильным во времени, то есть желательно, чтобы тот результат, который вы получили, он очень часто не менялся, тогда его как бы это смысл кошировать есть, если он часто меняется, то ваш кажет будет протухать довольно очень ничем быстро.

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

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

Опять же все зависит от ситуации, там вот конкретно ваша реализация, конкретно ваша программа, но в общем, случаев примеры вот такие. Так, давайте посмотрим на практически пример еще. Допустим, если у нас есть какая-то бюджер кустов валют и мы к внешне, на предоставляет нам свой BI, а мы в нашем приложении к ней к этому BI обращаемся. И создаем себе домашняя страничка, в этой домашней страничке мы хотим показать каких-то четыре валюты. Вот просто, на просто их текущий курс. Что для этого нужно?

Ну, прежде всего, четыре раза пробежать, допустим, форыча по всем тем валютам, которые мы хотим отобразить, взять аж степетлайн, сгонять на удаленный API, забрать оттуда этот курс и отремендерите его в нас локально на обычной страничке. О автора данный процесс занял почти четырестом или секунд. И каждый раз, когда вы открываете домашнюю страничку, она вас открывается минимум за четырестом или секунд. Это довольно медленно. Какие у этого подхода есть еще проблемы?

Ну, по-первых, четырестом или секунд это медленно. У нас все у нас четыре котировки. Если мы захотим больше, то это будет расти просто линейна. А дальше у нас может быть стоимость вызова API. Так как мы используем внешний сервис, этот внешний сервис может брать какую-то стоймаль за каждый вызов. Если мы там зашли на нашу страничку 10 раз, то, пожалуйста, ценнику нажать и надеюсь. Потому что на каждую заход на наш страничку идет вызов к этому внешним сервису.

Также у нас может быть стоимость какого-нибудь Cloud Hosting решения. То есть, у нас сейчас любит Cloud Pro-Wider брать деньги и там, и за DNS-лукап, и за routing, и за каждое обращение какому-то API, и за трафик и за все подряд. В этом примере у нас будет довольно много всяких обращений routing и в трафиков, поэтому там тоже могут за что-то подчаршить.

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

А сколько бустьер это мэмрикаш? Сколько нам даст, как бы преимущество по-перформоцию допустим? Если коротко, то мэмрикаш очень быстро. Самое, ну как он работает? Почему он добивается мега-быстроты? Добивается он очень просто, потому что он сохраняет ссылку на ваш объект, который на результат работы допустим ваша метода, он просто сохраняет себе ссылку.

Банальное сохранение ссылки имеет очень много преимущества, но во-первых, вам не нужно это как-то маршальть. Это не тратится время, потому что маршальненько это всегда очень медленнее. И во-вторых, он сам сообщает грабежкулектору, по сути, что собирать этот объект не нужно, не нужно. Это объект еще может пригодиться в будущем, и поэтому вы в своем из-за вашеем, пойдем можете просто просто про это забыть и не переживать, что объект куда-то идет.

Скорость мэмрикаша на даже запись чтения операции, это измеряется в десятках на на секунд. Поэтому вы этого даже не заметите. Особенно если будем сравнивать с нашим приведущим результатом. Когда мы говорим про каширование, всегда нужно в голове держать в альтернативу такой, как distribute it cash. Например, редис или ммк жди, или другие какие-то провайдеры, которые могут вам делать распределенные каширования. Они у них есть провайдеры, в тот найти их, то есть так же можете подключить.

В чём различия, ммркаша, локального и distribute it cash? В том, что distribute it cash располагается на какой-то внешней машине. Это значит, что никаких ссылок на дотный объект он не содержит. Это значит, что мы должны делать тот самый маршалинг. То есть обычно в distribute it cash охранятся или бинарные данные или текстовые данные, что-то такое. И для того, чтобы знашвая ассишарп объекта сделать текстовые для бинарные данные, существует процесса селизации и десерлизации.

То есть вы должны будете ваша объекта селизовать, десерлизовать, перенаправлять куда-то все, на какую-то другую машину, оттуда их считывать. Это всё намного медленнее, чем просто на просто, естественно, хранить ссылочку в памяти и всё. Но distribute it cashа есть свои преимущества, а они мы поговорим немножко по-папоже.

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

Если вы, например, никогда не удаляете ваши данные из памяти, только добавляйте их туда и читайте и всё, то на самом деле конкаран дикшен или от Strink Object будет намного быстрее инномарикэша. И вы вполне можете использовать его, но только помните, что если вы не оттуда ничего не удаляете, то у вас может быть какой-нибудь аутов ММР-эксэпшен, поэтому четко следите за память, затем что действительно туда много не складывайте.

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

Поэтому в этом случае он тоже вам нужно не подойти. Также полезно рассмотреть в таких перформанц критикал-вариантах использования специального класса, который называется Conditional Vick Table. Как вы наверное понимаете по названию, это штука, который оперирует с векре и ференцами и прочими вещами для того, чтобы сделать вам инномарикэш. Какие же проблемы есть у инномарикэша? Мне он не только висит себя хорошие и красивые, но у него есть такие темные стороны.

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

Как такое может подойти? Ну допустим, обе ноды прочитали правильные валидные данные из базы данных. И затем в одну из нод пришел запрос на изменения данных. Таким образом, номер 1 эти данные все поменяла, в кашейх тоже обновила, и они у него теперь свежие красивые. Но номер 2 ничего не знает, ни про какие обновления данных. Она продолжает пользователю отдавать данные старые.

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

И это более-менее не верирует данные проблемы. Другая проблема в номере каша это инвалидация данных. Как всем знаем, две самые больших проблемы, программирование это придумывание названий для переменных и инвалидация каша. В общем, здесь мы и куда-то этого не ушли.

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

У ИНОМРИКИША есть все необходимые методы для того, чтобы это сделать. Но вот когда их вызвать, это зависит от конкретного приложения, и такие места могут быть довольно ничевидными. Следующая проблема не то, чтобы ИНОМРИКИША просто криваруких разработчиков, но в общем, как бы сюда относятся. Это опасность того, что в каше засунут изменяемые структуры данных. Немножко пересекается, значит, первый темы.

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

И многие, многие, другие проблемы вас могут подсерегать, если вы используете изменяемые объекты в каше. Просто часы и дни отладки. Очень больно и очень неочевидно и очень страшные отладки могут вас подждать. Поэтому золотое правило, если вы используете каш каш, то есть, пользуете его только с неизменяемыми структурыми данных. Не поскупитесь на какую-то памяти или еще нам не моя что-то. Отладки и бессонные ночи, как б стоит намного дороже. Теперь давайте рассмотрим, как же нам завязать в ММРК.

Вот мы поняли, что это что-то. Хорошая, красивая, давайте подключим к нашему примеру. Для этого нам нужен пакет Microsoft Extension Caching Memory. И напрямую с ММРК шумой работать не будем. У него есть хорошая низкоуровня в интерфессе, которая называется iMMRK. Основные методы у него это создать в кашену, то есть, по сути, положить, в каш, попытаться достать сущность и скаша и удалить. Сущность и скаша. На основании трех этих примитивов можно сделать практически все, что нам нужно.

Но обычно с этими низкоуровними методами мы не работаем, потому что это совсем неудобно. Есть прекрасный метод расширение, как называется get or create. Он наверняка вам знаком по конкурендикшнере. С ним очень удобно управляться, и поэтому больше случаев используют именно его. Вашем приложении необходимо все ли садовать метод edm.end memory cache, которые добавят все необходимые интерфейсы.

В том классе, где вы обрабатываете непосредственно данный, вам необходимо заинжиксировать, внедрить интерфейс i memory cache. И заиспользовать его в нашем коде. Но например, если рассматривать наш пример с получением котировок, 4 валют. Прежде всего, при этом начали получать, в мэмории cache всегда нужно тщательно подойти к выбору ключа. Почему это так важно? Потому что если мы в качестве ключа выберем просто, например, название какой-то валюты и записываем его в cache.

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

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

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

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

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

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

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

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

Ну, все до не все, потому что на самом деле, если мы оставим наш пример в таком виде, то сколько раз мы на него не зашли, котировки будут всегда показываться одни те же. Менятся никогда не будут. А все потому, что мы просто запихнули данный вКш и не, каким образом не обновляем эти даты. К котировки нужно постоянно обновлять. Делается это намного, ну то есть, делается довольно просто, и мы в одной марикаже предоставляет огромную кучу стратегии, с помощью которых вы можете обновлять данные вКш.

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

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

Вот как бы, чем прикрасим виновым рекеше, чем он отличается в основном одичной. Его замечательными гипкомистартией гимуталения. Теперь давайте посмотрим. В принципе все это картинополучилось довольно хороший, из-за исключения момента, что мы очень сильно завязаны на InMemReCash. И эта завязка она у нас непосредственно в стратегии обработки прокинута. То есть мы напрямую рассчитываем на интерфейс ММРКш и логика получения данных напрямую завязано с тем, что мы езем inMMRKш.

Это не очень хорошо, потому что, например, в будущем мы можем передумать и подменить ММРКш на что-то другое. Например, на DistributeCash, в общем часто ситуация между прочим. Поэтому здесь было бы не плохо разделить ту логику, которая у нас есть для получения данных, то того потребителя, который читает эти данные и непосредственно абстракции вот этого киша. То есть, соответственно, тем, кто управляет коширивание. Самым первым вариантом, в котором стоит рассмотреть, это библиотека поли.

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

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

То есть вы можете положить в КС штулька, оттуда запись, которая допустим вернулась самая первая из трех различных запросов, которые были отправлены параллельные, при этом не было исключения, и при этом не было ретраив, при этом лимит не установлен, в общем все вот эти полевские нагрмождения, которые вы можете себе представить, они прекрасно дружат и с чего реализация ММРКш. Еще одна интересная альтернатива, которая стоит рассмотреть, это EasyCash.

EasyCash дает вам абстракцию на ткшом, но его основная фишка в другом. Отличат поли, он предоставляет огромное число провайдеров. Данных, где вы можете кушировать свои данные. Ну, естественно, ради СММКшди, SK Lite, обычные сквели, позгрессы, и много-много другой, в общем там список довольно богатый этих провайдеров. Поэтому если вы хотите, как каким-то образом гибко запоминать различные источники хранения информации и писать в них вот, EasyCash. Вполне может вам подойти.

Также нужно не забывать, что в приэрелизии у нас там готовится гибрид-кэш. Это такой мостик между Дистрибитом и ММРКшом. Эта реализация нам позволяет в определенные моменты времени хранить определенные данные в Дистрибитом и Дткш. А горячие на привык холодные данные в Дткш. А горячие данные, например, в ММРКш. В общем, и тут тоже стоит мостами поиграться. Кстати, EasyCash, на качестве одного там из провайдеров умеет поддерживать как раз уже гибрид-кэш.

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

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

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

И этот атрибут cash, например, может принимать и expiration time, например expiration time, допустим 30 минут. И все, это все, что вам нужно. Все с одной металлама сделает сама. Она сама вызовета, жти типа клайн, когда это необходимо. Самая закеширивает результат. И сама его почистит, когда истечет указанное время. Опять же, у металлама очень много минусов. Скорее всего, использовать ее не будете. Но как пример использования спектно-анитированного программирования?

В общем, вы должны знать, вы должны знать, что так можно делать. В общем, на этом погружение в номер к cash заканчивается. Если бы вдруг никогда не слышали про такой классство, обязательно на него посмотрите и заиспользуйте. А если слышали, то может быть открыть для себя какие-то новые спекты и какой-то новые способ использования, которым раньше не прибегали. Ну, каширование темоважное, без нее никуда.

Никуда в каком-то смысле, помоу, но если не в каждом, но у нас, наверное, в половине приложений в каком-то виде какое-то каширование где-то есть. Пусть даже хотя бы видит того самого конкаран-дикшинари, но уже пригождается. Бывает. Безстительно, если есть вероятность, что ваш cash потребуется делать разно. Как это сказать, это определенно. Вот, вспомнил слово, то лучше использовать что-то более стандартно-готовое стороне.

Такой вот оля и зекешен, или что-то такое, чтобы вы могли потом это делать заменить. На дисприбьют вот, когда потребуется. Это как с базой данных. Да, использую рем, чтобы иметь возможность заменить базу данных. Вот. Да, да, именно так. Ну ладно, давай пойдем сегодня на последнюю тему. У нас осталось маленькое последнее темко. Сейчас ее достану из благо. Вот она.

Это вижу в студии Preview 3. Естественно, обычно вместе со всякими шарпами, привьюшками и прочим, выходит соответствующая версия Preview. Как ни странно, в этот раз Preview нет практически ничего такого интересного. Там буквально пара фич про продуктивите. И в основном это касается Kotlens. Там немножко фикселя, значит, то как Kotlens работают. И в Полу реквест Creation, ты когда-то создаете Полу реквест прямо свяжу в студии, там добавилось некоторое количество улучшалок.

Теперь можно выбрать Target Branch. Это как-то для меня странно, потому что когда я сдаю Полу реквест, я как правила. Хочу оказать какому вранчику я Полу реквест делаю. Ну вот, теперь можно выбрать. А так же тебе... Видимо, это не всегда нужно. Ну нет, понятно, что в принципе можно найти общего, ближайшего приятка. И если это добрый прияток содержится всего в 2 убранчах, то, наверное, я хочу Полу реквест из моего убранча в другой убранчик.

Ну и тогда это то, почему прияток содержится больше, чем в 2 убранчах. И тогда вот начинается вопрос. В какой же убранчик я хочу биржить этот самый Полу реквест. Ну, видимо, действительно, сначала потяжали просещество, и теперь расширяют. Вот, причином, завално тоже написано, написано, что мы добавили Target Branch Selection, Comit Counts, то есть раньше нельзя было посмотреть, сколько комитов у тебя, в полу реквесте, при создании, видимо, в окошке создания.

И а также Адерс-Табилижейс-Стабилизацийшен фиксы. Что, как бы, для меня переводится, как, ну да, добавили, значит, это выборы ветки, количество комитов и другие фиксы, значит, про стабилизацию. Хотя, первый, два, явно, не про стабилизацию. Ну ладно. Ну и автоматически создание линков на те самые. Эти воркайты мы, которые вы упомянули в описании.

Ну и GitHub-капilot, как ты помнишь, ты чуть-чуть раньше сегодня говорил, давайте, мы уже в IntelliSense запишем там, дозанисело автогенерацию до комитации. Вот мы уже где-то там. Теперь в GitHub-капilot, если вы им пользуетесь, теперь если вы наводите мышку на нулик, курсор, когда что, вы поезд этот толстипчик, где написано, а что же за метод под курсором стоит? Там теперь можно сказать, Tell me more, нажать кнопочку, я понимаю.

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

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

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

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

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

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

Да, будем внимательно следить, и вы тоже, если подписывайтесь на наш подкастик, то обязательно не пропустите, никаких новых интересных, новых видений в Framework. Ну, что ж, если еще не подписались, подписывайтесь, комментарии оставляйте, друзья, завите, подкастик всем кидайте, и до следующих встреч. Всем пока! Всем пока!