Re[2]: Что наиболее быстро развивается? Замедлились ли телеф - Компьютерные священные войны

Здравствуйте, karbofos42, Вы писали:

K>Ну, у меня был комп с 256 МБ оперативы. Официальный клиент в жрал что-то около 20 МБ. QIP раза в 4 меньше, ещё и субъективно удобнее был.

У меня тоже был такой, но намного, само собой, позже. И да, ICQ там занимал сколько-то Мбайт.

PD>>Итого в результате обмена нескольких Кбайт (небольшая переписка) добавилось 18 Мбайт.

K>Кроме переписки там и история сообщений подгрузилась с картинками, превьюшками ссылок и т.п

Вся твоя история сообщений (с одним человеком) едва ли и на 100 Кбайт понянет. Ты сначала эти 100000 символов набери, а потом поговорим.

А картинки — ну да. Только вот в мессенджере хватит и тумбиналов, а сами картинки спокойно могут подгружаться, когда надо. Ты даже на 50 картинок одновременно смотреть не сможешь.

Там ведь не только картинки, там и видео может быть на десятки Мб, если не больше. Их тоже нужно все в ОП хранить ?

PD>>Что и требовалось доказать.

K>Ну, да. Наглядная иллюстрация подхода "Но пусть все это другое сидит на диске, пока не потребуется.".

Не понял. Он тебе не нравится ?

K>Если не переписывали, а стало жрать больше памяти, значит дело не в том, что разучились писать.
K>Компиляторы может память не жалеют, в ОС поменяли планировщик памяти или ещё что привело к повышенному потреблению.

Планировщик серьезно не меняли. А вот сами контролы переписали, да и стек тоже. Раньше все было ясно : user32.dll -> win32k.sys . Или kernel32.dll -_ntdll.dll -> ntoskrl.exe/ А сейчас чего-то там накрутили

K>Итого имеем стандартный Notepad, который написан под WinAPI и использует стандартные библиотеки и контролы, но у него за годы выросло потребление памяти в разы.
K>А те же мессенджеры используют Qt или ещё что-то для кроссплатформенности, т.к. нужно и винду и линукс и в веб ещё засунуть.
K>В той же ICQ не было никакого оформления сообщений (смайлики просто через замену символов работали). Сейчас и картинки можно со стикерами и markdown.

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

K>Мало кому заплатят денег под нативную реализацию для всех платформ. Обычно берётся что-то универсальное с кучей лишнего.

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

K>Думаю, что основное там — это библиотеки для GUI и т.п. Иначе не знаю чего там в ICQ напихали, что exe занимает больше 100 МБ. Хотя Qt отдельно 26 МБ лежит.

Это то выяснить несложно, посмотреть структуру EXE. Но не в этом дело. Если там 90% ресурсов, то ничего страшного нет. Понятно, что картинки надо где-то хранить, объем памяти при этом фиксирован. Вот только почему в ОП ?

K>20 лет назад кроссплатформа не так важна была и людям платили за разработку на WTL, MFC или голом WinAPI.
K>Сейчас на меня как на идиота посмотрят, если что-то из этого предложу.

Да, увы, тут ты прав.

Здравствуйте, Shmj, Вы писали:

Голосование по эффективности и расходам ресурсов

https://rsdn.org/poll/9966

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Shmj, Вы писали:

PD>Голосование по эффективности и расходам ресурсов

PD>https://rsdn.org/poll/9966
Павел, «ну кто так строит» (ц).

Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?

Насколько большой? Что за алгоритм (модифицирует массив или нет)?
Массив большой это что — по памяти или по числу элементов?

Имхо, тут сразу же всё упрется в структуры данных (векторы, деки, списки односвязные или двухсвязные) ну и.т.д.
А мы ж прекрасно понимаем, что структуры данных и алгоритмы обработки идут рука об руку. Для одних алгоритмов хороши одни структуры памяти, а для других другие (я в смысле идиомы: бинарный поиск азмЪ езмЪ гут, но уже извольте отсортированный массив подать).
Тут сразу же вспоминается Скотт Мейерс, с его клевыми рецептами.

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

Handle_Array_WithCopy(MyArray& ar);//функция с созданием копии
Handle_Array_NOCopy(MyArray& ar);//функция без копии

//общая функция - суть фасад, она сама выбирает какую реализацию звать. 
//А уж как выбирает - в рантайме, в дизайн-тайме, мрачно хардкодно - это уже детали
//Главное: эта фасадная функция скрывает доступ к деталям реализации
//PS: потом можно и открыть доступ к реализационным функциями отдельно.
//Главное в другом: по умолчанию реализацию лучше держать закрытой, и скрывать детали выбора 
//- чтоб через единственную точку доступа все шло - а именно через фасадную Handle_Array(MyArray& ar);
Handle_Array(MyArray& ar);

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Голосование по эффективности и расходам ресурсов

Зависит от кучи факторов.
Одно дело если это какая-то достаточно редкая функция.
Например, пользователь раз в месяц пользуется импортом из какого-то файла и там вызывается эта функция.
В итоге либо оптимизированный метод потратит 100 МБ памяти и 30 секунд процессорного времени, либо с копией — 200 МБ и 50 секунд.
В этом случае я напишу на копии, т.к. тут меньше шансов ошибиться самому и другим.
Сегодня я массив не редактирую и всё хорошо. Завтра в другом месте этот массив кто-то использует и опять всё хорошо.
Послезавтра ещё кто-то начнёт его редактировать и всё начнёт падать с непонятными ошибками.
Если же это часто вызываемая функция и в результате либо у пользователя периодические фризы, либо всё гладко будет работать, то там можно и неделю на оптимизацию потратить.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хорошая архитектура тем и отличается от плохой, что добавление фич ее не портит.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>https://rsdn.org/poll/9966

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

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

Здравствуйте, Carc, Вы писали:

C>Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
C>[/q]
C>Насколько большой? Что за алгоритм (модифицирует массив или нет)?

Я специально не стал конкретизировать. Вопрос такой — сделаете копию, если без копии сделаете за 4 часа, а с ней — за час ? Не важно, что там, время на разработку указано.

C>Массив большой это что — по памяти или по числу элементов?

А что, это не связано одно с другим как elems.size*sizeof(elem) ?

C>Имхо, тут сразу же всё упрется в структуры данных (векторы, деки, списки односвязные или двухсвязные) ну и.т.д.

Не важно. Вы можете за 1 час/ 4 часа сделать с ними или без них, быстрее не сможете.

Здравствуйте, karbofos42, Вы писали:

K>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Голосование по эффективности и расходам ресурсов

K>Зависит от кучи факторов.
K>Одно дело если это какая-то достаточно редкая функция.
K>Например, пользователь раз в месяц пользуется импортом из какого-то файла и там вызывается эта функция.
K>В итоге либо оптимизированный метод потратит 100 МБ памяти и 30 секунд процессорного времени, либо с копией — 200 МБ и 50 секунд.
K>В этом случае я напишу на копии, т.к. тут меньше шансов ошибиться самому и другим.
K>Сегодня я массив не редактирую и всё хорошо. Завтра в другом месте этот массив кто-то использует и опять всё хорошо.
K>Послезавтра ещё кто-то начнёт его редактировать и всё начнёт падать с непонятными ошибками.
K>Если же это часто вызываемая функция и в результате либо у пользователя периодические фризы, либо всё гладко будет работать, то там можно и неделю на оптимизацию потратить.

Нет шансов ошибиться (ну почти

, после функции этот массив никому не нужен. Чистый код. На входе массив, на выходе результат. Массив забываем, результат используем.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А картинки — ну да. Только вот в мессенджере хватит и тумбиналов, а сами картинки спокойно могут подгружаться, когда надо. Ты даже на 50 картинок одновременно смотреть не сможешь.

Если источник картинки отдельный механизм превьюшек не предоставляет, то придётся таки загрузить картинку, сформировать в памяти ужатый вариант для отображения пользователю, а полноразмерное выкинуть из памяти. Но программа всё равно вряд ли сразу память назад отдаст, подержит на всякий случай ещё какое-то время.
Ну, и кроме картинки, нужно загрузить библиотеку, которая умеет работать с набором в 100500 популярных графических форматов. Некоторые ещё и анимированные и там дополнительный механизм нужен.
Да и сама возможность прикладывать картинки усложняет формат передачи данных и увеличивает потребление памяти.
Можно один и тот же текст сохранить в txt и rtf и удивляться, что rtf больше занимает, хотя никакое форматирование не используется.

PD>Там ведь не только картинки, там и видео может быть на десятки Мб, если не больше. Их тоже нужно все в ОП хранить ?

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

PD>Не понял. Он тебе не нравится ?

Нравится. И нравится, что оно "само" работает, не нужно особо вручную ничего делать.

PD>Да уж. Чтобы добавить картинки небольшого размера, надо потребление памяти увеличить на 2 порядка.

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

PD>А вот это верно. Жертва качества за счет удовлетворения требований по скорости разработки, требованиям заказчика и т.д. Эффективность — в последнюю очередь, когда уж припрет.

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

PD>Это то выяснить несложно, посмотреть структуру EXE. Но не в этом дело. Если там 90% ресурсов, то ничего страшного нет. Понятно, что картинки надо где-то хранить, объем памяти при этом фиксирован. Вот только почему в ОП ?

Если на каждый чих бежать на диск, выкачивать очередную небольшую *.ico, потом выбрасывать её из памяти, то пользы от этого никакой не будет.
Для меня самого непривычно качать мессенджер на 300 МБ, ведь когда-то жесткий диск компа был на 200 МБ.
Но объективно на фоне современных объёмов ОЗУ это достаточно мало.
Когда-то на плюсовиков смотрели как на транжир, которые на свои бесполезные классы кучу памяти тратят.
Сейчас плюсовики уже выделываются тем какой у них язык нативный и ничего лишнего.

Здравствуйте, student__, Вы писали:

__>Конечно же, с копией. Потому что современная методология разработки ПО рассчитана на минимизацию длительности цикла разработки.
__>Эти 3 часа задерживают работу всех остальных отделов и команд, а если в результате окажется, что потребление памяти выходит за рамки, доступные в целевой системе,
__>всегда можно соптимизировать реализацию потом.

А не зря я дал 1 и 4 часа.

Вот если бы сказал — 1 день и 4 дня, тогда да, задержит работу, может быть. И то если график напряженный, а проект небольшой. Если проект на полгода — ничего не задержит. Будут тебе 23 февраля/8марта/1мая и что, вся работа полетит ?

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

__>Понятно, что если речь о какой-то встраивальщине, где физически не может быть достаточно памяти для копии массива, не имеет смысл реализация с копией,
__>но для системы общего назначения это не так, и даже в системах, в в принципе встроенные, но в которых довольно много памяти (не тупые микроконтроллеры, а мультимедийная часть инфотейнмент в авто), всегда каждая команда априори считает, что в их распоряжении вся память, доступная в системе для приложений, и оптимизационные мероприятия проводятся только если кому-то в процессе разработки этой памяти не хватает.

Вот поэтому мы и имеем то, что имеем.

Здравствуйте, karbofos42, Вы писали:

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

Придется. А вот отдаст или нет — это от программиста зависит. Если delete в С++ сделать — VM Size точно уменьшит. Из working set может, и не сразу удалит, но раньше или позже тоже.

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

Ох, что-то плохо верится в 100500. Их с десяток популярных, не больше. А прочие могут сидеть на диске и ждать, когда понадобится какой-то pcx распарсить.

Кстати, код занимает на удивление мало места. Попробуй dumpbin на любую DLL и увидишь сам. Основное — .data и .resource

K>Да и сама возможность прикладывать картинки усложняет формат передачи данных и увеличивает потребление памяти.

Что тут за такое усложнение ? Принять ее как файл (а она и передается как файл), записать на диск и ждать, пока ее не попросят показать

K>Можно один и тот же текст сохранить в txt и rtf и удивляться, что rtf больше занимает, хотя никакое форматирование не используется.

PD>>Там ведь не только картинки, там и видео может быть на десятки Мб, если не больше. Их тоже нужно все в ОП хранить ?

K>Видео даже при воспроизведении по-моему никто в памяти не хранит, а используют потоковую подгрузку нужных частей.

Верно. Потому что не поместится, это понимают. А картинки поместятся. Вот и не экономят. А памяти нужно все больше и больше...

PD>>Да уж. Чтобы добавить картинки небольшого размера, надо потребление памяти увеличить на 2 порядка.

K>Ну, можно и на отображении текста больше памяти тратить.
K>Когда-то на моноширных шрифтах сидели и нормально, а сейчас не только символы различных размеров могут быть, но и кернинги всякие реализовали.

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

K>Ну, это всегда так было. То под железо ужимались, упрощали и оптимизировали. Сейчас несколько другие критерии, но качество всегда страдало.

+1

PD>>Это то выяснить несложно, посмотреть структуру EXE. Но не в этом дело. Если там 90% ресурсов, то ничего страшного нет. Понятно, что картинки надо где-то хранить, объем памяти при этом фиксирован. Вот только почему в ОП ?

K>Если на каждый чих бежать на диск, выкачивать очередную небольшую *.ico, потом выбрасывать её из памяти, то пользы от этого никакой не будет.

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

K>Для меня самого непривычно качать мессенджер на 300 МБ, ведь когда-то жесткий диск компа был на 200 МБ.
K>Но объективно на фоне современных объёмов ОЗУ это достаточно мало.

Именно. Бери сколько можешь. Было бы сейчас не больше 1 Гб ОЗУ — хватило бы и его.

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

А это они всегда говорили. Я в том числе

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А 4 часа работу не задержат

Я бозначил общий подход, то, что разработчик с опытом в большом проекте (и не вчерашний студент) скорее всего выберет.
Чем больше и сложнее проект, тем больше в нём людей, и тем меньше свободы у того, кто занимается непосредственно реализацией.
В достаточно большой команде есть специальные люди, которые ничем другим не занимаются, кроме как вопросами анализа производительности.
Иногда для этого даже нанимаются сторонние фирмы.
К тому же, один программист может одновременно работать в нескольких проектах, и тогда 3 часа имеют значение, потому что если проекта 3, то 3 часа превращаются в 9, а это уже больше одного рабочего дня.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Carc, Вы писали:

C>>Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
C>>[/q]
C>>Насколько большой? Что за алгоритм (модифицирует массив или нет)?

PD>Я специально не стал конкретизировать. Вопрос такой — сделаете копию, если без копии сделаете за 4 часа, а с ней — за час ? Не важно, что там, время на разработку указано.
Ну я поэтому и написал, что сделал бы через фасадную функцию обработки массива. А та уж будет как-то выбирать функцию реализации.
А эти самые несколько разных функций разных реализаций будут работать по-разному. В зависимости от требований и главное их сочетаний: надежность, скорость, требования к памяти, как часто используется. Как верно написал _student, как часто оный функционал вовсе нужен пользователю (импорт\экспорт раз в месяц, или по 3 раза за минуту).
Мысль была в том, чтобы скрыть за фасадом выбор конкретных реализаций. Оставить себе свободу выбора на будущее, и в то же время полностью контролировать выбор в конкретный момент.

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

C>>Массив большой это что — по памяти или по числу элементов?

PD>А что, это не связано одно с другим как elems.size*sizeof(elem) ?
В математике связано. У пользователя нет. У пользователя нет математики: у него более приземленные понятия (быстро, надежно, тормозит\не тормозит, вызывает в UI какие-нить фризы и.т.д). И вот тут вот и всплывает то самое магическое sizeof(elem). Если там sizeof(long), то вроть и пофиг (для конечного пользователя системы), а если там sizeof(нихрена_себе_PFF-ка_с_жесткого диска), то очень даже и есть разница.
Дьявол — он в деталях. Универсального подхода здесь нет.

Здравствуйте, student__, Вы писали:

__>Я бозначил общий подход, то, что разработчик с опытом в большом проекте (и не вчерашний студент) скорее всего выберет.
__>Чем больше и сложнее проект, тем больше в нём людей, и тем меньше свободы у того, кто занимается непосредственно реализацией.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет шансов ошибиться (ну почти

, после функции этот массив никому не нужен.
Вооот, начинаются дополнительные ограничения.
"я забыл сказать — жителями этого дома будет семья глухонемых жирафов".
Наверняка ещё есть какое-нибудь невинное ограничение вида "предположим, что это именно C-style массив, то есть набор значений, плотно уложенных в непрерывной области памяти".
И всякие там произвольные уточнения вида "нет, мы не знаем, какую именно долю этого массива затрагивают изменения нашей функцией", "у нас есть гарантия того, что в параллельном потоке никто с этим массивом не работает ни на чтение, ни на запись", и т.п.

Насколько надёжно ваше доказательство того, что "после функции этот массив никому не нужен"?
Насколько надёжно предположение о том, что это не изменится в будущем?
Сможете ли вы написать код так, чтобы
а) использовалась in-place модификация
б) в случае, если окружающий код будет модифицирован так, что ссылка на оригинальный массив станет использоваться после вызова этой функции, то это вызовет compile-time error или иным способом защитит будущего программиста от выстрела себе в ногу?
в) даже если сможете — станете ли вы писать код именно таким способом, или самонадеянно нахреначите in-place версию, надеясь на авось?

Здравствуйте, Pavel Dvorkin, Вы писали:

__>>Понятно, что если речь о какой-то встраивальщине, где физически не может быть достаточно памяти для копии массива, не имеет смысл реализация с копией,
__>>но для системы общего назначения это не так, и даже в системах, в в принципе встроенные, но в которых довольно много памяти (не тупые микроконтроллеры, а мультимедийная часть инфотейнмент в авто), всегда каждая команда априори считает, что в их распоряжении вся память, доступная в системе для приложений, и оптимизационные мероприятия проводятся только если кому-то в процессе разработки этой памяти не хватает.

PD>Вот поэтому мы и имеем то, что имеем.

нет, не поэтому. В разработке ПО участвует не только программист. Он тут появляется уже на третьих ролях, как ни странно звучит. Сначала идут требования бизнеса — надо сделать вот это, мы это готовы продать за много денег, есть заказчики и сроки. Потом идут менеджеры/аналитики, которые говорят, что да, можно взять вот ту систему, добавить вот такой модуль и требования бизнеса закроются. Сроки — вот такие с учетом разработки и тестирования. И только теперь задача попадает к программисту, которому надо написать конкретный кусок кода в четкие сроки. Не уложишься — и твой супер красивый и быстрый код станет НИКОМУ НЕ НУЖЕН, потому что его некому продать, нишу заняли конкуренты, которые успели. А вот когда успели и продали, но например на машинах заказчика работает медленно, то тогда приходит команда перфоманс анализа, ищет те самые узкие места которые нужно оптимизировать здесь и сейчас и только потом снова идут к программисту с конкретным заданием. А если заказчика все устраивает, то вопрос оптимизации даже не возникнет, потому что некому будет платить за этот банкет. Вот как-то так — имеем то что имеем, потому что бизнес считает, что дешевле — потратить время на оптимизацию или купить железо покруче. И если железо дешево, то зачем оптимизировать, теряя деньги? Раньше же, в эпоху баснословно дорогого железа, упор был на оптимизацию, она стоила дешевле. Вот и все.

Здравствуйте, mike_rs, Вы писали:

_>нет, не поэтому. В разработке ПО участвует не только программист. Он тут появляется уже на третьих ролях, как ни странно звучит. Сначала идут требования бизнеса — надо сделать вот это, мы это готовы продать за много денег, есть заказчики и сроки.

Эти требования святой дух определил ? Сроки и прочее. Нет, они на основе предыдущих разработок сделаны.

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

Менеджерам и аналитикам эту информацию святой дух выдал ? Нет, они тоже основываются на предыдущих разработках.

>Сроки — вот такие с учетом разработки и тестирования. И только теперь задача попадает к программисту, которому надо написать конкретный кусок кода в четкие сроки. Не уложишься — и твой супер красивый и быстрый код станет НИКОМУ НЕ НУЖЕН, потому что его некому продать, нишу заняли конкуренты, которые успели. А вот когда успели и продали, но например на машинах заказчика работает медленно,

А заказчику святой дух объяснил, что тут медленно, и что нет ? Нет опять же, он на основе тех программ , что видел, делает свои предположения, сколько времени на что надо ?

>то тогда приходит команда перфоманс анализа, ищет те самые узкие места которые нужно оптимизировать здесь и сейчас и только потом снова идут к программисту с конкретным заданием. А если заказчика все устраивает, то вопрос оптимизации даже не возникнет, потому что некому будет платить за этот банкет. Вот как-то так — имеем то что имеем, потому что бизнес считает, что дешевле — потратить время на оптимизацию или купить железо покруче. И если железо дешево, то зачем оптимизировать, теряя деньги? Раньше же, в эпоху баснословно дорогого железа, упор был на оптимизацию, она стоила дешевле. Вот и все.

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

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

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

Мы сами их приучили так делать.

	От:	Stanislaw K
	Дата:	23.02.24 11:48
	Оценка:	1 (1) +1

	От:	Pavel Dvorkin
	Дата:	23.02.24 12:02
	Оценка:	+2

	От:	Pavel Dvorkin
	Дата:	23.02.24 12:12
	Оценка:

От:	Carc	https://vk.com/gosha_mazov
Дата:	23.02.24 12:54
Оценка:	+1

	От:	karbofos42
	Дата:	23.02.24 14:02
	Оценка:	1 (1) +2

	От:	student__
	Дата:	23.02.24 14:34
	Оценка:	1 (1) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	24.02.24 04:01
Оценка:	1 (1)

	От:	mike_rs
	Дата:	25.02.24 08:19
	Оценка: