LINUX.ORG.RU

Почему программы тормозят?

 


0

2

Сходу вижу следующих «виновников»:

  • Медленные запросы к субд / внешним (веб)сервисам.
  • Медленный дисковый (hdd) i/o.
  • Медленная сеть (большие задержки (latency) и/или пропускная способность).
  • Бесконечное бессмысленное копирование данных туда-сюда.
  • Блокировки на примитивах синхронизации (затраты на переключение контекста процесса/планировщик ядра).
  • Кеш-промахи.
  • Куча системных вызовов (syscall) с переключением в режим ядра.

Какие еще причины медленной работы ПО?
P.S. Кривая архитектура, алгоритмы и пр. ошибки проектирования не интересуют.

Ответ на: комментарий от quiet_readonly

quiet_readonly

Так ведь python. Сегодня на хабрахабре была статья, подробно объясняющая, почему языки со сборкой мусора хотят себе в 5 раз больше памяти, чем просит программист — и начинают тормозить, если им дают меньше.


Ссылку в студию, пожалуйста.

blackst0ne ★★★★★
()

Кривая архитектура, алгоритмы и пр. ошибки проектирования не интересуют.

почему? Почему тебя не интересует основная причина? Точнее:

Медленные запросы к субд / внешним (веб)сервисам.

Ошибка проектирование — не туда воткнули СУБД, не предусмотрели кеширование, использовали не ту СУБД и так далее.

Медленный дисковый (hdd) i/o.

мало оперативной памяти. Неправильный выбор железа, или неправильная архитектура кеша.

Медленная сеть (большие задержки (latency) и/или пропускная способность).

см. выше

Бесконечное бессмысленное копирование данных туда-сюда.

т.е. «бессмысленное» по твоему является хорошим, годным алгоритмом?

Блокировки на примитивах синхронизации (затраты на переключение контекста процесса/планировщик ядра).

кривая архитектура многозадачности/многопоточности. В терминальном варианте получилось-бы быстрее на одном ядре.

Кеш-промахи.

попытка закешировать всё подряд. Fail.

Куча системных вызовов (syscall) с переключением в режим ядра.

ну тут наверное надо было модуль делать, а не туда-суда щелкать. Ошибка проектирования...

drBatty ★★
()
Ответ на: комментарий от ilammy

Клёвый способ чинить баги — документировать их.

В данном случае это не баг, а поведение, которое описано в документации.

andreyu ★★★★★
()
Ответ на: комментарий от drBatty

Почему тебя не интересует основная причина?

Не в обиду конкретно вам сказано, но меня не интересует мнение маргиналитета ЛОРа относительно архитектуры и проектирования. Интересны детали на уровне пониже. В треде из толковых было только 2 сообщения: о GC, и об аллокаторах памяти (не сишный маллок, а те, которые с jvm и прочими vm).

nerdogeek
() автор топика
Последнее исправление: nerdogeek (всего исправлений: 1)

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

anonymous
()
Ответ на: комментарий от andreyu

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

типа с диском и видеокартой игрушки сами напрямую работают и таскают набор драйверов на все случаи жизни? Это, времена DOS давно прошли, если что.

anonymous
()

Программы тормозят всего по 2м причинам: 1. слишком много работают 2. слишком долго чего-то ждут. Первое умноженное на второе = проблемы.

DonkeyHot ★★★★★
()
Ответ на: комментарий от nerdogeek

Не в обиду конкретно вам сказано, но меня не интересует мнение маргиналитета ЛОРа относительно архитектуры и проектирования. Интересны детали на уровне пониже.

тащем-то своим вопросом ты уже очертил область своих знаний.

В треде из толковых было только 2 сообщения: о GC, и об аллокаторах памяти (не сишный маллок, а те, которые с jvm и прочими vm).

и в чём там толковость?

drBatty ★★
()
Ответ на: комментарий от drBatty

своих знаний

свох интересов. 4 проекта спроектировал и сдал в срок. мне пофиг на мнение лора в области проектирования. ну что не понятно?

и в чём там толковость?

в том что ответы релевантны вопросу. но ничего, дело привычное, лор он такой :)

nerdogeek
() автор топика
Ответ на: комментарий от nerdogeek

свох интересов. 4 проекта спроектировал и сдал в срок. мне пофиг на мнение лора в области проектирования. ну что не понятно?

ну тогда я тебя к классикам отправлю, начни с Кнута пожалуй...

в том что ответы релевантны вопросу. но ничего, дело привычное, лор он такой

релевантность это товар. Он стоит денег, которые ты не заплатил. Привыкай. Жизнь она такая.

drBatty ★★
()
Ответ на: комментарий от nerdogeek

на stackoverflow даже на откровенно тупые вопросы нормально отвечают.

что-то я не видел там ТАКИХ вопросов. Сдаётся мне их либо не задают, либо режут.

drBatty ★★
()
Ответ на: комментарий от nerdogeek

именно ТАКИЕ вопросы задают при приеме на работу в яндекс, если что

ну так бы сразу и сказал. Я думал, тебе проблему надо решить, а ты решил с помощью ЛОРа собеседование пройти...

Да, HR они такие, любят заставить кандидата на должность поделить на ноль, я в курсе. Они всё правильно делают кстати, и именно ещё и потому, что ЛОР таких как ты пошлёт... Ну ты понял.

drBatty ★★
()
Ответ на: комментарий от nerdogeek

в любом случае глупо перечислять следствия архитектурных просчётов, а потом говорить «архитектура меня не волнует». Надо было сразу сказать — «подскажите костыли, чтоб хоть как-то работало, и не настолько тупило».

А так ты всё правильно перечислил, могу ещё разве что добавить сильные тормоза, которые возникают при одновременной работе с одним ресурсом. Это и оперативная память, и HDD. Сама по себе скорость работы с ними может быть более чем достаточной, но вот доступность(латентность) часто и является бутылочным горлышком. А так вроде все симптомы перечислил. Ну раз лечить не нужно, то — удачи в ортопедии.

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.