Любопытно, а если бы... европейцы не поделились никакими доступами - получилось бы добиться такого же результата?
И ещё, почему сразу не отрубили все внешние доступы? - я подозреваю, что подвох в любой момент был ожидаем, как решились дожидаться шагов с той стороны?
...не понимаю праведного возмущения по поводу отжима. Как-бы вторая сторона сама сделала для этого всё возможное.
Не хочу занудствовать, но теперь уже реально хочется понять.
Т.е. иными словами, неявно каждый метод, в дополнении к результату возвращает и некий код результата/ошибки, который вывел и назначил компилятор, а каждый вызов оборачивается анализом с передачей результата в продолжение если код Ок, либо переходом в соответствующий обработчик/немедленным возвращением этого же кода вверх по стеку?
Теперь я правильно понял?
Если речь об этом, то концептуально это одно и то же.
И проблема остаётся той же: мы не можем с уверенностью собрать все возможные типы ошибок так, чтобы ко всему прочему оно оставалось верным и во время исполнения. А значит в реальной жизни одним из самых частых кодов ошибки будет что-то вроде АНЭКСПЕКТЕД_РЕТУРН_КОД.
Ну и отдельный большой вопрос - почему нужно делать именно так, чем оно лучше?
Я понимаю, компилятор/ИДЕ/анализатор может находить некоторое подмножество возможных исключений и показывать это программисту/помогать обрабатывать.
В этом был бы смысл, если бы было возможно найти ВСЕ везможные исключения метода/функции. Но это невозможно, см. примеры Интерфейса/Абстрактного класса/Рантайма новой версии/Плагина.
Значит либо программисту всё равно придётся лезть в документацию сторонних библиотек/свой код - и даже это не поможет в случае обновления рантайма/сторонних библиотек на исполняющей машине, либо он будет оперировать неполной (==ложной) информацией. Что в итоге даёт нам одинаковый результат.
Вывод: "нинада". Перефразируя: лови, что можешь исправить и будь, что будет.
Да при чём тут хедер - скомпилировали с хедером версии 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
Технично. Всё правильно сделали.
Любопытно, а если бы... европейцы не поделились никакими доступами - получилось бы добиться такого же результата?
И ещё, почему сразу не отрубили все внешние доступы? - я подозреваю, что подвох в любой момент был ожидаем, как решились дожидаться шагов с той стороны?
...не понимаю праведного возмущения по поводу отжима. Как-бы вторая сторона сама сделала для этого всё возможное.
Собственно, к чему я и вёл.
Пропустил слово: одним из самых частых ОБРАБАТЫВАЕМЫХ кодов ошибки будет что-то вроде АНЭКСПЕКТЕД_РЕТУРН_КОД.
Имелось ввиду "любой".
Не, любопытно было чем этот подход кажется лучше исключений. В сравнении с го [мне] понятно в чём смысл.
Не хочу занудствовать, но теперь уже реально хочется понять.
Т.е. иными словами, неявно каждый метод, в дополнении к результату возвращает и некий код результата/ошибки, который вывел и назначил компилятор, а каждый вызов оборачивается анализом с передачей результата в продолжение если код Ок, либо переходом в соответствующий обработчик/немедленным возвращением этого же кода вверх по стеку?
Теперь я правильно понял?
Если речь об этом, то концептуально это одно и то же.
И проблема остаётся той же: мы не можем с уверенностью собрать все возможные типы ошибок так, чтобы ко всему прочему оно оставалось верным и во время исполнения. А значит в реальной жизни одним из самых частых кодов ошибки будет что-то вроде АНЭКСПЕКТЕД_РЕТУРН_КОД.
Ну и отдельный большой вопрос - почему нужно делать именно так, чем оно лучше?
Ну, я про исключения - возвращение по стеку до ближайшего обработчика с сохранением какой-либо информации об исключительном собитии. А вы?
Я понимаю, компилятор/ИДЕ/анализатор может находить некоторое подмножество возможных исключений и показывать это программисту/помогать обрабатывать.
В этом был бы смысл, если бы было возможно найти ВСЕ везможные исключения метода/функции. Но это невозможно, см. примеры Интерфейса/Абстрактного класса/Рантайма новой версии/Плагина.
Значит либо программисту всё равно придётся лезть в документацию сторонних библиотек/свой код - и даже это не поможет в случае обновления рантайма/сторонних библиотек на исполняющей машине, либо он будет оперировать неполной (==ложной) информацией.
Что в итоге даёт нам одинаковый результат.
Вывод: "нинада". Перефразируя: лови, что можешь исправить и будь, что будет.
Примерно такой у меня ход мысли на этот счёт.
для этого ничего, кроме документации АПИ не нужно.
Да при чём тут хедер - скомпилировали с хедером версии 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