Да при чём тут хедер - скомпилировали с хедером версии 1.1, в рантайме доступна версия 1.2, на уровне сигнатур функций полностью совместимы, а список исключений изменился.
Никто ничего не факапит. Усложним: Программа предоставляет плагину некоторое окружение, в том числе функции/проперти, есть списки исключений. Система скомпилирована, версия 1.1. Третья контора написала под эту версию плагин, плагин свободно продаётся. У пользователя система версии 1.2, плагин скомпилированный под версию 1.1. АПИ бинарно совместимы, список исключений системы версии 1.2 отличается.
Что скомпилированный плагин может знать об исключениях рантайма новой версии?
Классический пример: скомпилировали с одной версией сторонней библиотеки, на машине пользователя установлена библиотека с секьюрити/хот фиксом, новая версия, список исключений отличается.
Ну и плагины, да - пользователь может написать свою логику и бросить дллку в фолдер приложения. Что приложение может знать об исключениях плагина?
Зачем "просить компилятор"? Знаешь как восстановиться после любого исключения - ловишь все, знаешь, как восстановиться после конкретных - ловишь их, не можешь восстановиться - не ловишь ничего. Чего сложного-то?
А зачем? Нет, серьёзно, какой практический/прикладной смысл?
Как отследить исключения, если метод вызывает метод интерфейса или абстрактного класса? А если метод, из сторонней библиотеки, которая существует только в виде бинарника? А если метод плаг-ина?
Большинство советов по оптимизации плохие, или сформулированы так, что в большинстве случаев окажутся вредными.
Для затравки начнём с вот этого утверждения: "Использовать явный тип вместо var (-3%)" - я, кхм, позволю себе усомниться ;)
О более серьёзном: "оптимизировать на быстродействие, нужно помнить, что это чёрная магия и плата за её использование велика – ... увеличение расходов памяти в несколько раз"
Это одно из самых странных заявлений, что я слышал об оптимизации на данный момент ;) Мне сложно представить, что именно должно к этому приводить, не поделитесь? ;) Разве что был выбран алгоритм, который выполняется быстрее за счёт потребления большего объёма памяти, ну так и что в этом плохого?
В целом, для оптимизации быстродействия первый же совет - минимизировать количество индивидуальных аллокаций, переиспользовать созданные инстансы, не создавать коллекций, внутренние массивы которых попадут в LOH, Поэтому первым делом читаем про ArrayPool и изобретаем подходящий к случаю инстас пул. А там где возможно - переходим от классов к структурам и массивам структур.
Дальше, векторизация и т.д. и т.п. Даже "базовая", которой "пользуется" BCL уже даёт более чем ощутимый прирост производительности. Важно то, что нам не нужно "отсекать" пользователей с устаревшими ЦПУ. Достаточно:
Использовать Span где это возможно (уже почти всюду)
Использовать специально написанные для Span методы из стандартной библиотеки - от реализованных в MemoryExtensions и Vector, до всяких TensorPrimitives.
Этого уже будет достаточно для заметного увеличения скорости (на машинах, поддерживающих векторные операции).
Теперь отдельно про Parallel.
Никогда не использовать вложенные Parallel и в целом вложенное распаралеливание.
Parallel с неуказанным явно MaxDegreeOfParallelism исходит из того, что в его распоряжении все ядра, соответственно этому планирует нагрузку/партишнинг. Если один из его тасков начинает ветвиться, то часто получаем "переполнение" очереди планировщика, что приводит к неоптимальному выполнению и излишним аллокациям для запланированных тасков и прочей асинк-машинерии.
В целом Parallel совсем не подходит для hot path. Ок, если у вас раз в 10 минут пользователь нажимает кнопку и вы там что-то считаете на локальной машине - то ок, но если у вас на сервере достаточно часто запускаются процессы, которые выполняются минутами/часами - то я бы не стал использовать Parallel: он слишком высокоуровневый, поэтому у него достаточно много "накладных" расходов и "вручную" можно сделать гораздо оптимальнее для конкретного случая.
Плюс Parallel "провоцирует" писать так, чтобы как минимум на каждый его вызов происходила аллокация для захвата локальных переменных - что в вашем рекомендованном коде и происходит (хотя этого можно, а в случае горячего пути и нужно избегать).
Вообще, совет, который я мог бы дать из своего опыта: оптимизируйте однопоточный алгоритм, оптимизируйте однопоточную реализацию, если возможно - разбейте исполнение на независимые партиции и исполните паралельно. Если невозможно - вернитесь к алгоритму и постарайтесь сделать его "партицирукмым" :)
И что, все в один голос клянут проклятый механизм?
Я к тому, что если мнение теоретическое и обывательское (а не, скажем, основанное на работе с анализом кампаний/боевого применения), то почему упускается из виду тот факт, что достаточно популярных мнений (в мире, в том числе) по поводу АЗ/МЗ не одно, а как минимум 3?
Чтобы сделать коллекцию, вы просто повторяете тег.
И что вы ожидаете найти в спецификации XSD?
Ну, как ожидаю? Я находил. К примеру, можно найти как описываются повторящиеся элементы и из этого сделать вывод, как наиболее... разумно сериализовать коллекцию. К примеру - практически как в JSON, т.е.
Хотя, опять же, если вдруг разработчику схемы по каким-либо соображениям приспичило сериализовать так, как описано - нет проблем, будет работать. И даже валидную XSD для такого можно написать.
Предложенные варианты чего? У нас есть API сторонней библиотеки, которое ожидает что мы будем отдавать запрошенный тип для указанного поля, в том порядке, в котором она попросит. Какие еще варианты реализации вы бы предложили?
Так я не понял, это сторонняя библиотека требовала на вход такой XML?
Впрочем, не важно, удивление моё адресовано авторам новаторского подхода к сериализации пропертей-коллекций.
Но, повторю ещё раз: и так тоже можно, если очень надо. Просто неоднозначно и странно.
Несколько нелогично, по-моему, упоминать подобное как претензию к XML
Чисто формально - .НЕТ открытый проект, куда бы МС не ушёл, на возможность пользоваться .НЕТом это не повлияет.
Дальше, .НЕТ - от рантайма-джита, через базовую библиотеку и до дизайна языка и компилятора - громадный и интереснейший кусок знаний (и опыта), развивающийся у нас на глазах.
Так что хотя бы с этой точки зрения должно быть познавательно.
Ну и возвращаясь к уходу МС - было бы, конечно, здорово и интересно всё это импортозаместить - да хотя-бы даже реализовать рантайм-джит для Эльбруса или только MAUI для авроры (или как там её?), но я/ты/он/она такое организовать не потянем, а заинтересованности у тех, кто мог бы, к сожалению, не заметно. А могло бы стать шагом к какой-нибудь православной хармони-ос.
для этого ничего, кроме документации АПИ не нужно.
Да при чём тут хедер - скомпилировали с хедером версии 1.1, в рантайме доступна версия 1.2, на уровне сигнатур функций полностью совместимы, а список исключений изменился.
Никто ничего не факапит. Усложним: Программа предоставляет плагину некоторое окружение, в том числе функции/проперти, есть списки исключений. Система скомпилирована, версия 1.1. Третья контора написала под эту версию плагин, плагин свободно продаётся. У пользователя система версии 1.2, плагин скомпилированный под версию 1.1. АПИ бинарно совместимы, список исключений системы версии 1.2 отличается.
Что скомпилированный плагин может знать об исключениях рантайма новой версии?
Не понял, честно говоря.
Классический пример: скомпилировали с одной версией сторонней библиотеки, на машине пользователя установлена библиотека с секьюрити/хот фиксом, новая версия, список исключений отличается.
Ну и плагины, да - пользователь может написать свою логику и бросить дллку в фолдер приложения. Что приложение может знать об исключениях плагина?
Зачем "просить компилятор"? Знаешь как восстановиться после любого исключения - ловишь все, знаешь, как восстановиться после конкретных - ловишь их, не можешь восстановиться - не ловишь ничего. Чего сложного-то?
А зачем? Нет, серьёзно, какой практический/прикладной смысл?
Как отследить исключения, если метод вызывает метод интерфейса или абстрактного класса? А если метод, из сторонней библиотеки, которая существует только в виде бинарника? А если метод плаг-ина?
Большинство советов по оптимизации плохие, или сформулированы так, что в большинстве случаев окажутся вредными.
Для затравки начнём с вот этого утверждения: "Использовать явный тип вместо var (-3%)" - я, кхм, позволю себе усомниться ;)
О более серьёзном: "оптимизировать на быстродействие, нужно помнить, что это чёрная магия и плата за её использование велика – ... увеличение расходов памяти в несколько раз"
Это одно из самых странных заявлений, что я слышал об оптимизации на данный момент ;)
Мне сложно представить, что именно должно к этому приводить, не поделитесь? ;)
Разве что был выбран алгоритм, который выполняется быстрее за счёт потребления большего объёма памяти, ну так и что в этом плохого?
В целом, для оптимизации быстродействия первый же совет - минимизировать количество индивидуальных аллокаций, переиспользовать созданные инстансы, не создавать коллекций, внутренние массивы которых попадут в LOH,
Поэтому первым делом читаем про ArrayPool и изобретаем подходящий к случаю инстас пул.
А там где возможно - переходим от классов к структурам и массивам структур.
Дальше, векторизация и т.д. и т.п. Даже "базовая", которой "пользуется" BCL уже даёт более чем ощутимый прирост производительности. Важно то, что нам не нужно "отсекать" пользователей с устаревшими ЦПУ. Достаточно:
Использовать Span где это возможно (уже почти всюду)
Использовать специально написанные для Span методы из стандартной библиотеки - от реализованных в MemoryExtensions и Vector, до всяких TensorPrimitives.
Этого уже будет достаточно для заметного увеличения скорости (на машинах, поддерживающих векторные операции).
Теперь отдельно про Parallel.
Никогда не использовать вложенные Parallel и в целом вложенное распаралеливание.
Parallel с неуказанным явно MaxDegreeOfParallelism исходит из того, что в его распоряжении все ядра, соответственно этому планирует нагрузку/партишнинг. Если один из его тасков начинает ветвиться, то часто получаем "переполнение" очереди планировщика, что приводит к неоптимальному выполнению и излишним аллокациям для запланированных тасков и прочей асинк-машинерии.
В целом Parallel совсем не подходит для hot path. Ок, если у вас раз в 10 минут пользователь нажимает кнопку и вы там что-то считаете на локальной машине - то ок, но если у вас на сервере достаточно часто запускаются процессы, которые выполняются минутами/часами - то я бы не стал использовать Parallel: он слишком высокоуровневый, поэтому у него достаточно много "накладных" расходов и "вручную" можно сделать гораздо оптимальнее для конкретного случая.
Плюс Parallel "провоцирует" писать так, чтобы как минимум на каждый его вызов происходила аллокация для захвата локальных переменных - что в вашем рекомендованном коде и происходит (хотя этого можно, а в случае горячего пути и нужно избегать).
Вообще, совет, который я мог бы дать из своего опыта: оптимизируйте однопоточный алгоритм, оптимизируйте однопоточную реализацию, если возможно - разбейте исполнение на независимые партиции и исполните паралельно. Если невозможно - вернитесь к алгоритму и постарайтесь сделать его "партицирукмым" :)
Огромная просьба: проверьте, пожалуйста, можно ли во время разговора отключить микрофон (mute)? - есть ли такой жест или, может быть, можно настроить?
Если mute есть - работает ли при звонках через Teams и тому подобный софт на пк?
Если быть точным, то не запретили.
Запретили использовать await внутри lock:
А lock внутри async - пожалуйста:
Это тоже, скажем мягко, не аксиома, да и не так, чтобы правда.
Кстати, одно из мнений гласит, что "из-за угла" можно и вручную заряжать, а вот при маневрировании автоматика сильно помогает.
Я к чему?
К тому, что "самая первая претензия" к российским танкам, на деле - весьма дискуссионная тема.
И что, все в один голос клянут проклятый механизм?
Я к тому, что если мнение теоретическое и обывательское (а не, скажем, основанное на работе с анализом кампаний/боевого применения), то почему упускается из виду тот факт, что достаточно популярных мнений (в мире, в том числе) по поводу АЗ/МЗ не одно, а как минимум 3?
В каком полку служили?
Или с топваровских фронтов?
del
Ок, с этим не поспоришь.
Да, тут нужна схема или определение соответствующего типа на языке программирования - что на моём опыте в 99% случаев наличествует.
И вообще - при публикации XML API не публиковать схему - нехорошо.
...но возможно ;)
Ну, как ожидаю? Я находил. К примеру, можно найти как описываются повторящиеся элементы и из этого сделать вывод, как наиболее... разумно сериализовать коллекцию. К примеру - практически как в JSON, т.е.
Хотя, опять же, если вдруг разработчику схемы по каким-либо соображениям приспичило сериализовать так, как описано - нет проблем, будет работать. И даже валидную XSD для такого можно написать.
Так я не понял, это сторонняя библиотека требовала на вход такой XML?
Впрочем, не важно, удивление моё адресовано авторам новаторского подхода к сериализации пропертей-коллекций.
Но, повторю ещё раз: и так тоже можно, если очень надо. Просто неоднозначно и странно.
Несколько нелогично, по-моему, упоминать подобное как претензию к XML
Это сейчас всерьёз, про коллекции?
Хоть бы в спецификацию xsd кто заглянул, прежде чем... новаторствовать.
Предложенные варианты вообще ни в какие ворота, конечно, НО - они работают, если уж так прям нужно.
Не настолько.
Плюс ламбда в EF не компилируется.
Да и мусор от них вряд ли переживёт ген0 при таком использовании.
дел
Чисто формально - .НЕТ открытый проект, куда бы МС не ушёл, на возможность пользоваться .НЕТом это не повлияет.
Дальше, .НЕТ - от рантайма-джита, через базовую библиотеку и до дизайна языка и компилятора - громадный и интереснейший кусок знаний (и опыта), развивающийся у нас на глазах.
Так что хотя бы с этой точки зрения должно быть познавательно.
Ну и возвращаясь к уходу МС - было бы, конечно, здорово и интересно всё это импортозаместить - да хотя-бы даже реализовать рантайм-джит для Эльбруса или только MAUI для авроры (или как там её?), но я/ты/он/она такое организовать не потянем, а заинтересованности у тех, кто мог бы, к сожалению, не заметно.
А могло бы стать шагом к какой-нибудь православной хармони-ос.
И вас, судя по всему, могут сильно удивить настроения большой части этой общины
Кому и кобыла невеста, конечно