исключения в С++ считаются медленными

а на самом деле — они медленные?

... и почему в других языках они — стандартная практика?

Потому что они медленные для всяких «числодробилок»? И потому что на многих задачах это неважно, но для этих задач и С++ не особо нужен?

нет

http://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow

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

они почти везде медленные, вопрос только в их кол-ве на ед. времени.

и почему в других языках они — стандартная практика?

в каких ЯП, где они есть, исключения не стандартная практика?

в каких ЯП, где они есть, исключения не стандартная практика?

За исключением сабжа,таких не знаю

сабж не исключение.

Почему исключения в С++ считаются медленными?

Потому что они медленнее, чем «нормальный» путь выполнения кода

и почему в других языках они — стандартная практика?

1) Потому что в этих языках за счет оверхеда VM «основной» путь выполнения тоже медленный

2) При наличии JIT часто выбрасываемое исключение будет прооптимизировано

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

В некоторых других языках может происходить что-то подобное(например, если сборка мусора реализована как подсчет ссылок + детектор циклов).

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

ящитаю это зачет, вместо того, чтобы поискать информацию о stack unwinding, надо прийти в Development и создать очередной долбоящерский тред. лор клоака

http://habrahabr.ru/post/208006/

1. Почему исключения в С++ считаются медленными?

потому что бесплатного сыра не бывает. ещё бывает кривая реализация раскрутки стека в ос.

2. ... и почему в других языках они — стандартная практика?

потому что «другие языки» медленнее даже исключений в крестах.

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

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

Например, в питоне их даже рекомендуется кидать по поводу и без

не всегда работает на сто процентов безопасно

это смотря где. в линаксе небезопасно, но относительно быстро. в фрибзде — наоборот.

и то, и другое суть есть

кривая раскрутка стека

их несовместимость с сишным кодом, или иногда даже с системными библиотеками

древние неактуальные байки. любой современный компилятор прописывает аналог gcc_personality и для сишного кода.

несовместимость между кодом разных компиляторов

исключения чем здесь выделяются? это касается всех крестов целиком. abi собирались стандартизировать в c++17, но, видимо, не осилят.

Например, в питоне их даже рекомендуется кидать по поводу и без

Кто?

почему в других языках они — стандартная практика?

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

И не стоит путать количество проверок на ошибки и бросков исключений в коде с количеством реальных бросков в рантайме. Другое дело, что сами проверки типа if (error) throw могут съедать процессорное время. Для этого стоит пользоваться встроенными командами вроде GCC-шного __builtin_expect.

это смотря где. в линаксе небезопасно, но относительно быстро. в фрибзде — наоборот.

а можно поподробнее? хотя бы линк, где про это почитать.

Основная проблема скорее не в том, что они «медленные», а в том, что они не time deterministic, а потому совсем не пригодны для риалтайма.

... и почему в других языках они — стандартная практика?

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

линка нет, но общее направление указать могу.

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

хотя вру, линки есть

для линакса даже на лоре: Разделяемая библиотека и thread safety

для фрибзди — на офсайте: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131597

Например, в питоне их даже рекомендуется кидать по поводу и без

Использование питона намекает на то, что производительность в данной задаче побоку.

Следи за базаром, сява. Как «исключение» может быть «нормой»?!?

Они считаются (и являются) более медленными, чем классическая обработка ошибок на основе кодов (либо возвращаемых из функции, либо глобальных вроде errno). Кроме этого они имеют ещё несколько недостатков: раздувают размер бинарника (независимо от того, используются исключения реально или нет), затрудняют отладку (особенно радует, когда какой-то «чудак» начинает на них городить логику), имеют сложный ABI (проброс исключения через несколько разделяемых библиотек, собранных разными компиляторами, может подарить много радостных часов в отладчике). В общем, есть плюсы и минусы.

Тогда java.

Например, в питоне их даже рекомендуется кидать по поводу и без

Кто?

Толстые аноны

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

Иначе, на них потом альтернативно одарённые начинают стейт машины строить.

пока исключение не выстрелило, ты за него ничего не платишь

зависит от реализации поддержки исключений

кривая реализация раскрутки стека в ос.

сам хоть понял, что сказал?

sjlj на практике уже трудно встретить, так что можно считать что бесплатно

с каким словом ты не согласен?

в С++ исключения шлются калбеком,проходя прослойку от ядра/иксов/glib/стандартной библиотеки/библиотек IO/...путь до твоего кода...и выполнение твоего кода на исключение-очевидно вобщем,чем длиннее путь тем дольше,исключения описанные в пределах одного бинарника(«аргумент» исключения не внешняя библиотека)-будет работать также как условие if/else (также медленно,если учитывать что if самая медленная операция для ЦП)

в JIT-прелоадинг и прекомпайлинг плюс шаблоны сценариев-ускоряют исключения до скорости case/switch в томже движке(что быстрее if/else в томже движке,но в разы медленее нативных компиляторов)

пока исключение не выстрелило, ты за него ничего не платишь

Ещё как платишь, насколько много — зависит от реализации исключений. В лучшем случае, размером бинарника. В каких-то реализациях компилятор может добавлять какие-то телодвижения на входе в каждую (!) функцию и/или блок try-catch

Иначе, на них потом альтернативно одарённые начинают стейт машины строить.

кстати да,это забавно выходит

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

в линуксе тоже если исключение ждать от DE гнома/кде-которые скрипотовые...тоже самое что в винде

#! /usr/bin/env python3

def noexc(n):
    a = []
    for i in range(n):
        if len(a) > 0:
            a[0]

def exc(n):
    a = []
    for i in range(n):
        try:
            a[0]
        except IndexError:
            pass

if __name__ == '__main__':
    from sys import argv
    N = 128*1024*1024
    if len(argv) > 1:
        noexc(N)
    else:
        exc(N)

$ time ./slow_exceptions.py 

real    1m13.330s
user    1m13.172s
sys     0m0.000s

$ time ./slow_exceptions.py no

real    0m18.698s
user    0m18.528s
sys     0m0.104s

Т.ч. в других языках тоже медленные.

В любом языке интерпретатор или компилятор может считать «исключительный» путь менее вероятным, может кроме случаев когда JIT слишком умный и придумает как оптимизировать исключения, когда они более частые. Но если теоретически предположить что мы напишем такой код на Java, где есть хотя бы малые шансы, на то что JIT такой умный, то все равно обычный цикл по сравнению с аллокацией обьектов в цикле сольет немеряно. Потому мне кажется ты тут меряешь скорость создания обьектов в том числе

реализация механизма раскрутки стека при при выбрасывании исключения никаким боком к ос.

забавно,на «высокоуровневых» исключениях,типа IO/памяти(где и логично использовать исключения а не х-рить в цикле) не замечал такой большой просадки,но да-твойже код на java

http://pastebin.com/kPzYzKG5

> time java psx

real	0m0.352s
user	0m0.370s
sys	0m0.006s

> time java psx no

real	0m0.153s
user	0m0.165s
sys	0m0.004s

и у меняже на питоне(твой код)

> time python3 py.py

real	0m32.799s
user	0m32.769s
sys	0m0.002s

> time python3 py.py no

real	0m7.858s
user	0m7.851s
sys	0m0.001s

(абажаю сравнивать питон и джаву,не мог удержаться сори)

удивительное рядом...

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

Хех...вспомнилась шутка про throw ziga

ОС про C++ исключения вообще не в курсе, так что проблемы негров ...

зато ос берётся запускать elf-ы не умея правильно с ними работать. ещё ос местами не в курсе того что программы могут быть многопоточными.

зато ос берётся запускать elf-ы не умея правильно с ними работать

Раскрой подробности о том, какое elf-ы имеют отношение к исплючениям в C++

eh_frame. и не только к исключения, и не только к с++

Спасибо. Пойду почитаю о чем там речь.

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

Начнем с того, что экспешен это, «ненормальное поведение» программы и кидаются они как раз в ситуациях, когда полимеры так и так просраны (в той или иной степени) так что пофиг на time deterministic.

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

так что пофиг на time deterministic.

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