Александр Семелит
@bashnesnos
Программист широкого профиля
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Works in
- Date of birth
- Registered
- Activity
Программист широкого профиля
Information
При внимательном изучении обнаружил «Осень 2014» и «Весна 2015». Т.е. 2-3 квартала. Это круто, конечно.
Я согласен и не спорил с вами по поводу
Я согласен, что
На нём в общем-то всё и завязано в статье — т.е. на выяснении того, что на требуемом нам количестве скорость ок, или не ок.
Я пытался донести, что подразумеваю под «обработкой записи» наиболее практический аспект обработки записи — «элементарную операцию» (тут можно отдельно закопаться), количество которых можно рассчитать с помощью функции сложности.
Я намеренно упростил этот момент, и я не вижу смысла усложнять его обратно введением «элементарной операции» вместо «обработки записи».
Думаю стоит добавить отдельную оговорку про среднее время на обработку записи в рассматриваемом мной контексте.
В таком случае вопрос будет исчерпан?
Например, википедия:
Т.е. если мы подставим в функцию временной сложности размер входных данных (в рассмотренном мной случае он известен из требований), то получим максимальное количество операций (в худшем случае). Тут сложность заканчивается. Далее, зная требуемое время выполения и кол-во операций можно посчитать требуемое время выполнения одной операции в среднем.
В моём примере выше выполнений цикла 10000, и если нам нужно чтобы весь цикл выполнился за 2 секунды на одно выполнение цикла в среднем сколько получится?
Действительно, стоит прекратить дискуссию, раз вы не готовы аргументировать свою позицию и искать точки соприкосновения.
Сколько будет выполнений внутреннего тела цикла в примере ниже? 100 или 10000?
Вы подтверждаете, что сложность описывает связь между количеством элементов, временем обработки одного элемента и временем обработки всех элементов. Задача, которую я рассмотриваю в этой статье — обратная. Т.е. исходя из ограничений на время обработки всех элементов, и зная количество элементов определить ограничение на время обработки одного элемента. Вы же не будете отрицать, что 4000/20^2=10?
Сложность говорит не только о росте, поскольку время обработки алгоритма O(n) и O(n^2) всё-таки сильно отличается при одном и том же значении n — как раз по той причине, что нужно сделать выполнить больше операций над одним и тем же количеством элементов.
Но поскольку необходимы результаты, а не бесконечное стремление к идеалу — даже в таких условиях будут какие-то необходимые и достаточные для внедрения на прод требования по производительности, на которые надо ориентироваться.
Несколько штрихов:
У внешнего пользователя, т.е. у человека есть границы восприятия, быстрее которых нет смысла оптимизировать (например https://www.nngroup.com/articles/response-times-3-important-limits/). Границы меняются с адаптацией человека к технологиями и эволюцией человека, но всё же они есть — т.е. не каждое увеличение быстродействия будет замечено.
У бизнеса ориентированного на пользователя тоже нет смысла улучшать бесконечно, потому что у продукта который он предоставляет пользователю есть 3 состояния качества — лучше чем у конкурента, хуже чем у конкурента и так же как у конкурента. Если уже лучше — то зачем тратить деньги кроме пиара, если хуже — то вопросов нет, если так же, но есть другие преимущества — то тоже особо нет смысла.
И конечно же у каждого бизнеса разные возможности, поскольку улучшение от 15 до 10 секунд стоит одних денег, от 10 до 3 секунд других денег и от 3 до 1 секунд — третьих денег.
невиновностикомпетентности в первую очередь, поскольку программисты это в первую очередь люди и уже потом инженеры.Некомпетентность компенсируются мощью поисковых машин при наличии сомнений и желания, чаще этим запретом манипулируют менеджеры, а не инженеры.