Классический пример: скомпилировали с одной версией сторонней библиотеки, на машине пользователя установлена библиотека с секьюрити/хот фиксом, новая версия, список исключений отличается.
Ну и плагины, да - пользователь может написать свою логику и бросить дллку в фолдер приложения. Что приложение может знать об исключениях плагина?
Зачем "просить компилятор"? Знаешь как восстановиться после любого исключения - ловишь все, знаешь, как восстановиться после конкретных - ловишь их, не можешь восстановиться - не ловишь ничего. Чего сложного-то?
А зачем? Нет, серьёзно, какой практический/прикладной смысл?
Как отследить исключения, если метод вызывает метод интерфейса или абстрактного класса? А если метод, из сторонней библиотеки, которая существует только в виде бинарника? А если метод плаг-ина?
Большинство советов по оптимизации плохие, или сформулированы так, что в большинстве случаев окажутся вредными.
Для затравки начнём с вот этого утверждения: "Использовать явный тип вместо 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 для авроры (или как там её?), но я/ты/он/она такое организовать не потянем, а заинтересованности у тех, кто мог бы, к сожалению, не заметно. А могло бы стать шагом к какой-нибудь православной хармони-ос.
Не понял, честно говоря.
Классический пример: скомпилировали с одной версией сторонней библиотеки, на машине пользователя установлена библиотека с секьюрити/хот фиксом, новая версия, список исключений отличается.
Ну и плагины, да - пользователь может написать свою логику и бросить дллку в фолдер приложения. Что приложение может знать об исключениях плагина?
Зачем "просить компилятор"? Знаешь как восстановиться после любого исключения - ловишь все, знаешь, как восстановиться после конкретных - ловишь их, не можешь восстановиться - не ловишь ничего. Чего сложного-то?
А зачем? Нет, серьёзно, какой практический/прикладной смысл?
Как отследить исключения, если метод вызывает метод интерфейса или абстрактного класса? А если метод, из сторонней библиотеки, которая существует только в виде бинарника? А если метод плаг-ина?
Большинство советов по оптимизации плохие, или сформулированы так, что в большинстве случаев окажутся вредными.
Для затравки начнём с вот этого утверждения: "Использовать явный тип вместо 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 для авроры (или как там её?), но я/ты/он/она такое организовать не потянем, а заинтересованности у тех, кто мог бы, к сожалению, не заметно.
А могло бы стать шагом к какой-нибудь православной хармони-ос.
И вас, судя по всему, могут сильно удивить настроения большой части этой общины
Кому и кобыла невеста, конечно
И что из этого неправда?
Так а что имеется ввиду под "плохо переваривает долгие CPU-bound задачи"?
Вообще, долгая CPU-bound - это идеальная задача с точки зрения производительности, часто недостижимая.