Используя Исключения, добавляющие C#. Это влияет на производительность?
В этот век PowerShell я бы редактировал PATH следующим образом:
$PATH = [Environment]::GetEnvironmentVariable("PATH")
$xampp_path = "C:\xampp\php"
[Environment]::SetEnvironmentVariable("PATH", "$PATH;$xampp_path")
Чтобы задать переменную для всех пользователей в масштабе машины, последняя строка должна выглядеть следующим образом:
[Environment]::SetEnvironmentVariable("PATH", "$PATH;$xampp_path", "Machine")
В сценарии PowerShell вы можете проверить наличие вашего C:\xampp\php перед добавлением в PATH (в случае, если он был добавлен ранее). Вы можете обернуть его в условное выражение if.
Итак, все вместе:
$PATH = [Environment]::GetEnvironmentVariable("PATH")
$xampp_path = "C:\xampp\php"
if( $PATH -notlike "*"+$xampp_path+"*" ){
[Environment]::SetEnvironmentVariable("PATH", "$PATH;$xampp_path", "Machine")
}
8 ответов
Рекомендации Microsoft по дизайну для разработки библиотек классов - очень ценный ресурс. Вот соответствующая статья:
Исключения и производительность
Я бы также порекомендовал книгу Framework Design Guidelines из Microsoft Press. В нем много информации из ссылки Design Guidelines, но она аннотирована людьми с РС и самим Андерсом Хейлсбергом. Это дает возможность понять, «почему» и «как» обстоят дела.
Если вы беспокоитесь о производительности исключений, вы неправильно их используете.
Но да, исключения влияют на производительность.
Создание исключения - дорогостоящая операция в C # (по сравнению с другими операциями в C #), но недостаточная, чтобы я этого не делал.
Я согласен с Джаредом, если ваше приложение работает значительно медленнее из-за создания и выброса исключений, я бы посмотрел на вашу общую стратегию. Вероятно, что-то можно реорганизовать, чтобы сделать обработку исключений более эффективной, вместо отказа от концепции создания исключений в коде.
выполнение кода с помощью оператора try / catch вообще не влияет на производительность. Единственный удар по производительности наступает, если генерируется исключение ... потому что тогда среда выполнения должна раскрутить стек и собрать другую информацию, чтобы заполнить объект исключения.
То, что сказали другие люди, плюс:
Не используйте исключения как часть процесса программирования. Другими словами, не создавайте исключение для чего-то вроде account.withdrawalAmount> account.balance . Это бизнес-кейс.
Другой важный момент, на который следует обратить внимание в отношении производительности, - это проглатывание исключений. Это скользкая дорожка, и как только вы разрешите своему приложению принимать исключения, вы начнете делать это везде. Теперь вы можете разрешить своему приложению генерировать исключения, о которых вы не знаете, потому что вы их проглатываете, ваша производительность страдает, и вы не знаете почему.
Это не глупо, просто я видел это где-то еще на SO.
Исключения случаются хорошо, когда вещи действительно исключительные. В большинстве случаев вы повторно генерируете исключение (может после регистрации), когда шансов на восстановление после него не так много. Так что это не должно вас беспокоить при нормальном ходе выполнения программы.
Исключения, как следует из названия, являются исключительными. Следовательно, нельзя ожидать, что они были важной целью для оптимизации. Чаще всего они не работают, поскольку у них есть другие приоритеты, такие как сбор подробной информации о том, что пошло не так.
Исключения в .NET влияют на производительность. По этой причине их следует использовать только в исключительных случаях.