Что почитать по оптимизации и ресурсоемкости операций?

https://wiki.python.org/moin/TimeComplexity теория

https://docs.python.org/3/library/profile.html#instant-user-s-manual практика

Я бы порекомендовал почитать что-нибудь из теории сложности алгоритмов. А конкретные операции в конкретных языках после этого становятся частными случаями. Если у Вас есть более-менее приличная математическая база, то посмотрите этот курс:

http://lectoriy.mipt.ru/course/Maths-ComputationalComplexity-14L

Честно, я его не смотрел, но смотрел мой друг. Сказал, что хороший, но изложение предполагает хороший фундамент.

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

Use the profiler, Luke

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

cProfile / SnakeViz

Если ты уперся в производительность встроенных структур, то скорее всего ничего не поможет. Или переходить на cython или менять алгоритм. Можешь Седжвика почитать, он очень легко заходит.

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

Поясни, пожалуйста. Меня прежде всего волнует банальное время выполнения. Можно же сказать, какие операции быстрее, какие медленнее, в каких случаях? А в каком-нибудь php какие функции проще и быстрее?

Я бы порекомендовал почитать что-нибудь из теории сложности алгоритмов.

Теория, а вернее то, что вы под ней понимаете и то, что находится по твой ссылке - это рассуждения про отношения.

Знание того, что у васи козлов в 2раза больше, чем у пети баранов - не даёт тебе ответа на вопрос «сколько у пети баранов, а у васи козлов».

http://lectoriy.mipt.ru/course/Maths-ComputationalComplexity-14L

Абсолютно не применимо на практике, ибо всё основано на моделях протухших ещё до рождения лектора. Рассуждения про np смысла не имеют, как и рассуждения про пузырёк и подсчёт кол-ва «шагов».

Да и сама теория сложности смысла не имеет, а нужна только для абстрактного сравнения алгоритмов и то на невнятных условиях, ибо сравнение работает когда сравнивается пузырёк и кусорт, а когда когда надо сравнить 2 реальных алгоритмы - садится в лужу. Уже начинается переход на полную теорию, где появляются не только временные отношения, но и другие типы ресурсов, про которые он написал.

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

«ресурс память нужен только для оценки занимаемой памяти» - рили? Не знаю как в радужных сранах с пони, но в этом мире память это не мистический зверь, а такая же операция требующая времени. Больше мапяти - больше надо прочитать.

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

Жизнь она такая и в ней сложение медленней умножения.

Вот-вот из этой серии что можно почитать? Желательно без особых деталей (я не специализируюсь на ИТ).

Можно же сказать, какие операции быстрее, какие медленнее

Можно, но не в случае тебя и не в случае питона.

Меня прежде всего волнует банальное время выполнения.

Ты его может просто померить.

А в каком-нибудь php какие функции проще и быстрее?

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

Если это понимание у тебя есть - пхп и питон тебе не нужны, ибо твоя квалификация будет в области ниже и решать задачи тебе по статусу будет положенно иные. Понимание же в мире пхп/пистона не имеет смысла, ибо тебе ничего не даст.

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

Профайлер и минимальные способности к анализу полученной информации - твоё решение.

Вот-вот из этой серии что можно почитать?

Ничего. Там нюансов столько, что понимание этого факта потянет за собою всё остальное.

Желательно без особых деталей (я не специализируюсь на ИТ).

Уж точно ничего.

Как ты себе вообще представляешь какое-либо точное понимание процессов без деталей?

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

Если ты не можешь оценить - ты измеряешь. Для этого тебе детали не нужны. Я выше писал об этом. Но это не оценка снизу, но этого достаточно для ответов на твои вопросы.

Ты его может просто померить.

Я знаю. Суть вопроса в том, что может быть кто-нибудь померил уже. Чтобы мне в это смотреть и писать хорошо сразу, а прыгать с линейкой времени потом, перебирая варианты.

Я имел ввиду не почему умножение быстрее сложения (хотя для общего развития было бы интересно, если бы это можно было кратко объяснить, но суть моего вопроса не в этом), а сам этот факт. Умножение быстрее сложения. А как соотносятся сложение и вычитание? А логические операции?

Учитывая, что я не о понимании спрашивал, твой ответ:

Можно же сказать, какие операции быстрее, какие медленнее?

Можно, но не в случае тебя и не в случае питона.

остается в силе?

Это ты же moscwich? Есть пара вопросов по РЖД)

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

Погуглить про конкретную операцию или что там тебе нужно?

Ты хочешь какие-то рецепты «что юзать чтобы было быстрее» - маловероятно что такое есть. Каждая «операция» делает что-то своё, даже если для реализации какого-либо частного случая подходят более одной «операции», но это не значит что одна быстрее/лучше другой в общем случае. Поэтому результирующий труд должен содержать не только кол-во операций, но ещё всё это в степени их применений - это невозможно.

Если такие есть, то они будут обмусоливать пару пунктов заливая их водой. Что-то типа:

Всё просто - сахар, особенно на таких слабых реализациях как у питона/пхп - стоит чего-то. А любой язык - это сахар над си. Поэтому дедовский совет «пиши как на си» - работает всегда, если не сравнивать их с внутренними реализациями языка.

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

Остальное уже частные случаи и гугли надо конкретно по теме.

Понял. Так и получается, да — как на Си...

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

Я вообще от профессионального программирования далек, программирую или для воплощения каких-то мат. моделей в реальность, или просто для рассчетов. Еще для фана иногда.

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

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

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

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

Это относится именно к самому факту.

Умножение быстрее сложения.

Нет. Не быстрее. Это свойство конкретных реализацих в конкретных случаях. Без этого конкретики говорить о «быстрее» не имеет смысла и ты только обманешь окружающих и себя запутаешь.

Воспринимать ты это должен так - есть такой частный факт, а не правило. Этот факт направлен на то, чтобы адепты не путали «операция сложнее» и «быстрее».

Ты вцепился в это, но это бесполезно. Ты не прочитал основную мысль, а именно - там было написано, что само понятие «быстрее» мало применимо и имеет мало смысла.

А как соотносятся сложение и вычитание?

Это одно и то же.

Ещё раз - все рассуждения об этом не имеют смысла.

Учитывая, что я не о понимании спрашивал, твой ответ:

Ты спрашивал именно про него, а то, что ты этого не понимаешь - не делает мой ответ не ответом, либо ответом на другой вопрос.

Всё зависит от нюансов, а не от «фактов» в твоём понимании.

остается в силе?

В силе что?

Нет. Не быстрее. Это свойство конкретных реализацих в конкретных случаях. Без этого конкретики говорить о «быстрее» не имеет смысла и ты только обманешь окружающих и себя запутаешь.

Понял.

Это одно и то же.

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

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

Он не плохой - он хороший и пацан нормальной рассказывает и не заикается каждую секунду.

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

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

А как ещё? Если тебе вся эта оценка и результат не принципиален, то естественно не нужно. Нужно когда результат не устраивает тебя.

Понимание просто даёт возможность оценивать результат ещё до написания чего-то, а не после.

Лучше сложить в голове более-менее целостную картину происходящего и логически рассуждать в каждом конкретном случае.

Логики в этих теориях ровно ноль. Картину она никакую не создаёт - путает и забивает головы адептов догматами, верованиями, авторитетами и прочим.

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

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

Для работы логики не нужны никаких теории нерабочие - она или есть, либо её нет. Для развитии логики надо изучать подходы и решать задачи.

По крайней мере она дает четкие ответы на многие вопросы вида

Нет. Это враньё. Ничего она не даёт.

«возможно ли это за обозримое время»

Этот вопрос не имеет смысла. А если он тебе так важен - он выводится безо всяких теорий.

«какой из двух алгоритмов лучше работает при очень больших n».

То же нет. Я уже разбирал этот вопрос выше.

Во-первых никому не интересно «какой лучше» - всем интересно «какой реализум», «какой реализуем быстрее, в смысле времени выполнения сортировки"и прочее.

Вам дурят голову всякими пузярькамивскусорт. Это не имеет смысла. Если же уже возьмём набор вменямых алгоритмов - уже никто не ответит. Какой из десятков логнов лучше?

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

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

Если он менее сложен - он менее сложен при любых n, если он зависит от n.

Ещё раз - оценка сложности оценивает сложность, а вернее рост его с ростом н. Никакого отношения к конкретным величинам она не имеет.

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

Ты не согласился со мною, а после привел довод, который я так же привёл. Но я привел его точнее.

Есть конструкции языка/апи рантайма, а есть сахар. strchr() - это не сахар над циклом, а конструкция. А вот ренжфор сахар над обычным фором. Шанс на то, что под какой-то сахар будет запилена отдельная оптимизация стремится к нулю, а вот шанс на то, что на неё забьют - крайне вероятен и в лучшем случае её просто сведут к не сахарному варианту.

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

Где-то даже пример был, что вот вариант с сахаром работает быстрее, чем аналогичный, но расписанный на 3 строки.

Это мало что доказывает. Написать эти 3 строчки можно как угодно. Да и если ты видел всего один пример - это только доказывает его несостоятельность, ибо в противном случае их были бы милилоны.

Вас слишком сильно зомбируют и вы путаете причины и следствия. Мне очень часто доказывают пацаны что-то типа „сложности не знаешь - будешь юзать пузырёк“, „без сложности был бы только пузырёк“ и прочие куллстори. Каким образом метрику оценки, причём кривую приравнивают к самим алгоритмом мне не ведомо. Как ты способность к оценке приравниваешь к какой-то конкретной теории оценки - мне так же неведомо.

https://wiki.python.org/moin/PythonSpeed/PerformanceTips

https://docs.python.org/3.5/library/profile.html

Меня лично никто не зомбирует. Да и вообще алгоритмы несколько выходят из круга моих интересов.

Если что, я математик. И порядок роста функции от типа роста отличаю. И ассимптотически неравенства от обычных неравенств тоже отличаю.

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

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

Сразу добавлю свое мнение на счет приложения теории сложностей. Оценка абстрактной сложности алгоритма, как правило, дает лишь порядок роста функции (а иногда не дает, а оценивает). Для того, чтобы определить тип роста нужно рассматривать конкретный случай. И для определения типа (т.е. по сути конкретных коэффициентов) нужно будет задействовать статистические методы везде, где есть элемент случайности.

Меня лично никто не зомбирует. Да и вообще алгоритмы несколько выходят из круга моих интересов.

А кто признается-то? Все самобытны и думают, примают решения сами. Ну по мнению их самих.

Если что, я математик. И порядок роста функции от типа роста отличаю. И ассимптотически неравенства от обычных неравенств тоже отличаю.

А я птушник.

А у Вас слишком громкие и безапеляционные заявления.

Да нет же - я всё объяснил и аргументировал. Вы считаете их такими по причине того, что они противоречат линии партии, а ей противоречить нельзя - это та самая вера в авторитеты про которую я там выше говорил.

Я верю в Ваш опыт

Птушник я без опыта - в мой опыт верить не надо - его нет.

но не переоценивайте его по сравнению с накопленным за столетием опытом многих людей.

Я не умоляю заслуги людей. Но заслуги их находятся в мире радужных пони, которые иногда спускаются в этом бренный мир.

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

Только я не понимаю - оценка сложности нужна для чего? Сейчас оно сама по себе и с реальным миром мало соприкасается.

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

Как бы объяснить попроще. Вот у нас есть спидометр, который даёт погрешность в сотню км/ч. Конечно - можно оправдать это тем, что на «больших скоростях» и «он позволяет оценить скорость», но толку с этого? Мы живём в реальном мире, где есть конкретные числа и для них это не работает.

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

Я не применяю её - зачем мне применять то, что с мой ТЗ бесполезно?

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

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

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

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

Это невозможно по определению(вывести из общего частное, если это не предполагается, а это не предполагается). Поэтому в любом случае придётся снизу изобретать новую систему оценки и зачем-то подгонять её под убогий обобщенный шаблон - зачем? Конкретное - оно самодостаточно.

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

Оценка абстрактной сложности алгоритма, как правило, дает лишь порядок роста функции (а иногда не дает, а оценивает).

Порядок оценивается и без теорий.

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

Т.е. оказывается нужна ещё одна в 100раз более сложная теория, которой нет? Отлично. Зато есть теория под оценку порядка, который оценивается любым, кто умеет в понимание описания и арифметику.

Теория сложности не преподносит себя не так, как вы описали, а уж её апологеты и подавно. Приписывая её достижения всего и вся. По вашему описанию она просто не имеет смысла как что-то фундаментальное. Просто обобщенная метрика - не более.

Но почему все её преподносят как что-то эдакое и так яро реагируют на любые выпады против неё?

Я верю в Ваш опыт

Напрасно.

А во всех процессорах в мире типа одинаковые блоки для всех операций, да?
Сказать можно, но серьёзная оптимизация требует точного исчисления, а для простой будет достаточно и профайлера.
Ибо там важнее структура кода, а чтобы банально не засрать проект блоатом достаточно банального понимания операции на примитивном уровне.

Ты же понимаешь что последовательное чтение один раз запрошенного списка эффективней запроса из базы каждого отдельного элемента? Ну и этого уровня вполне хватит.