Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет kouzdra ([info]kouzdra)
@ 2014-06-02 15:47:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Нашел у себя здоровенную дыру в перформансе на С++ (gcc):
В примерно 30% времени жрала плюсовая обработка throw. Причем стек сворачивался неглубоко - десяток позиций без объектности. 20 000 исключений ужирали примерно секунду реального времени.

В принципе догадывался - но таки вляпался.

PS: Тоже самое кстати относится и к dynamic_cast - тоже дикий тормоз. Лучше через виртуальные методы кастинг делать где скорость важна.


(Читать комментарии) - (Добавить комментарий)


[info]p_k
2014-06-02 20:30 (ссылка)
Угу. RTTI и исключения тормозят, как я понимаю из-за того, что их обработка включает сравнение строк (имен классов). И от этого никак не избавиться, поскольку throw и catch могут быть в разных compilation units.

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2014-06-03 11:51 (ссылка)
Там не в именах дело - просто наворот довольно сложный - там же наследование еще (в том числе множественное потенциально), ну и exceptions же еще стек динамически сворачивают - а в С++ это автоматом означает выполнение зоопарка деструкторов (чего как раз и нет в ML и Java)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]p_k
2014-06-03 12:59 (ссылка)
Конечно, stack unwinding дает дополнительный оверхед, но это касается только исключений (да и то если были походу созданы стековые объекты). А вот dynamic_cast, пр котором тоже раскрутки не происходит, все равно медленный, и дело тут именно в строках.

(Ответить) (Уровень выше)


(Читать комментарии) -