MicMicvde69тут самое главное - не выплеснуть с водой ребенка, то есть оптимизировать стоит не ради оптимизации а ради результата видимого потребителю.

Я бы сказал правильно сформулировать цель оптимизации и критерии оценки.Лучше изначально писать оптимизированный код.Bone serpentdenis2828,

В 1С оптимизировать нужно, в первую очередь, алгоритм, потом всякие индексы и планы запросов. Всё остальное, за редким исключением, категорически не критично для быстродействия.Открываем стандартную бухгалтерию, и смотрим что происходит при проведении документа.... ВЕШАЕМСЯ на алгоритме

Bone serpentПрограммист 1сЛучше изначально писать оптимизированный код.

Оптимизированный для чего? По каким критериям? Код может быть оптимизирован по быстродействию, размеру, потреблению памяти, поддержке и всему прочему.Расскажите про оптимизацию только расхода памяти или только поддержки. Не стесняйтесь привести пример нехватки 128ГБ памяти.
Вы уверены что занимались хоть раз оптимизацией в среде 1с?
Bone serpentПрограммист 1сОткрываем стандартную бухгалтерию, и смотрим что происходит при проведении документа.... ВЕШАЕМСЯ на алгоритме
Признаться не замечал. Нормальный код, читабельный. Это вам не write-only языки типа perl. Может у вас просто знаний предметной области недостаточно, что бы учетные алгоритмы читать?То есть для Вас главный критерий это читабельность описания? А сам алгоритм уже не важен... Может у Вас не хватает понимания для того чтобы алгоритмы оптимизировать?

Последний выдох ГПЖ>Не стесняйтесь привести пример нехватки 128ГБ памяти.

при наличии отсутствия вменяемого толстого клиента проблемы до сих пор актуальны иногда при расходе памяти > 3,5 Гб... какие там 128 Он еще не сказал про какую память. Может мы говорим уже о физической...

А вообще это был сарказм про 128гб. Примеров то нет.

Bone serpentПрограммист 1сРасскажите про оптимизацию только расхода памяти или только поддержки.
Как ни крути, по всем критериям одновременно оптимизировать нельзя. Вдобавок, если разные среды исполнения. Один и тот же алгоритм+реализация может вполне эффективно работать в локалке в толстом клиенте, но, например, быть неэффективным в тонком клиенте.
Программист 1сНе стесняйтесь привести пример нехватки 128ГБ памяти.
Сразу на 128ГБ замахиваетесь? А что делать с вашими "системными требованиями" тем, у кого толстый клиент? Каждому пользователю по 128 гигов вставлять? Или тем, у кого терминал на Windows Server Standart? А куда вы дели ограничение выделенной памяти на процесс?
Программист 1сВы уверены что занимались хоть раз оптимизацией в среде 1с?
И 1С, и не 1С... За два десятка лет в ИТ многое было :)
Программист 1сТо есть для Вас главный критерий это читабельность описания? А сам алгоритм уже не важен... Может у Вас не хватает понимания для того чтобы алгоритмы оптимизировать?
Важен, важен. Просто после того, как обрёл опыт писания отраслевых решений и поддержки всего этого с изменениями законодательства, несколько изменился взгляд на типовые алгоритмы 1С и истоки их возникновения.Примеров оптимизации под 1с не будет? Если Вы только теоретик, простите на Вас время бессмысленно.

Bone serpentПрограммист 1сПримеров оптимизации под 1с не будет? Если Вы только теоретик, простите на Вас время бессмысленно.
Наоборот. Замшелый практик. И считаю, что оптимизация имеет смысл, когда устраняет "бутылочное горлышко". Пока узкое место не определено, заниматься оптимизацией, только зазря тратить деньги работодателя. Так что это вы теоретизируете на тему "сферической оптимизации в вакууме".
«Преждевременная оптимизация — это корень всех бед» (С) Тони ХоарЗабавно. Пишите паршивенький код и гордитесь этим?

Последний выдох ГПЖя не пойму предмет вашего спора, честно... как маленькиеНе дай бог AHDP увидит ветку.
Он может к любому слову придраться.

Регулярно выискиваю узкие места у своих и предлагаю оптимизировать. (Запустил округление 100 строк товара - всего 10 секунд потребовалось ). Не проще изначально делать правильные соединения, хорошие индексы, так чтобы потом в данный запрос вообще не пришлось залезать? (даже если где-то просядет производительность, можно быть уверенным что причина не здесь.)

Bone serpentПрограммист 1сЗабавно. Пишите паршивенький код и гордитесь этим?
Вы писание просто нормального кода, без быдлокодинга, с оптимизацией не путайте.
Когда у вас нормально написанный алгоритм с допустимой скоростью и загрузкой ресурсов обрабатывает, к примеру, и десять и сто тысяч номенклатурных позиций, а на 500 тысячах тормозит и падает, вот тут начинается настоящая потребность в оптимизации.Тоесть написать изначально паршивый код который будет тормозить при 500т это нормально? Изначально его написать так чтобы не пришлось оптимизировать нельзя? Узнаю почерк сранчевской логики. Сделаем вшивенько - клиент сам к нам придет. Мы же не обязаны глянуть что у клиента 500т - на 10 строчках работает, и ТАК СОЙДЕТ...

Bone serpentПрограммист 1сНе проще изначально делать правильные соединения, хорошие индексы, так чтобы потом в данный запрос вообще не пришлось залезать?
В каких-то ситуациях да, в каких-то нет. Вы, например, учитываете, что добавление индекса к таблице замедляет запись в неё? А какое соотношение количества чтений и количества записей в вашей абстракной таблице, на которую индекс вешать собираетесь?А вы например учитываете положение урана в формирование плана запроса? Тоесть опять же сранчевская логика - плевать на то что мы можем предсказать что в 99% случаев надо сделать А, в остальных Б. Мы лучше сделаем Б, клиент сам прибежит.

Bone serpentПрограммист 1с,
Тоесть написать изначально паршивый код который будет тормозить при 500т это нормально? Изначально его написать так чтобы не пришлось оптимизировать нельзя? Узнаю почерк сранчевской логики. Сделаем вшивенько - клиент сам к нам придет. Мы же не обязаны глянуть что у клиента 500т - на 10 строчках работает, и ТАК СОЙДЕТ...

Написать изначально паршивый код который будет тормозить при 500т - это вполне нормально. Точно так же, как, например, разработчики этого сайта не пишут код, не используют оборудование и технологии, которые потянут количество пользователей уровня фэйсбука. И вы сами не будете покупать грузовичок вместо легковушки только потому, что, может быть, раз в год нужно будет привезти три урожай картошки с поля домой. Потому что код, который эффективно работает на 500т совсем не обязательно будет эффективно работать на 100шт. К примеру, банальная тупая сортировка пузырьком на малых объёмах данных эффективней всех крутых и навороченных алгоритмов, способных сортировать терабайтные массивы.
Излишний перфекционизм вреден. Неумение расставить приоритеты тоже плохо. Вы будете тратить деньги заказчика/работодателя (ну или свои, если на сдельщине) с малой эффективностью. Про то умные люди и сказали: «Преждевременная оптимизация — это корень всех бед».Не надо рассказывать про то что не относится к 1с. Конкретно в 1с - примеров нет и не будет? Только Болтологией занимаетесь?

Почему не упомянули применение квантовых эффектов при сборе картошки? Глупо не разбираясь в 1с, лезть со стороны "терабайтных массивов". Может сначала включить мозги и проверить их наличие в 1с?Bone serpentА вы например учитываете положение урана в формирование плана запроса? Тоесть опять же сранчевская логика - плевать на то что мы можем предсказать что в 99% случаев надо сделать А, в остальных Б. Мы лучше сделаем Б, клиент сам прибежит.
Может всё же лучше определять узкие места и их оптимизировать, чем их "предсказывать"?А это оценка уровня интеллекта. Если Вы этого не умете - селяви. Отсюда на выходе и получаем постоянные сранчевские доделки. Неумение комплексно мыслить, приводит к дальнейшим глобальным и возможно практически не устранимым ошибкам в проекте.