Процедура с объектом и без

[northener]

Сообщение от Vapaamies

Плюс, в отличие от многих, я прекрасно помню, как в свое время приходилось учиться в одиночестве и при отсутствии информации (Интернета еще не было)

+100500
Первую свою (ещё учебную) написал в 1979. Первую не учебную в 1982. Учебную на фортране для ЕС ЭВМ, не учебную на паскале для уже и не помню как это чудище называлось, но некий аналог IBM PC.

[northener]

Вспомнил. Чудище называлось Искра 1030.

[Kronos913]

Сообщение от Vapaamies

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

Прошу прощения. Да, понимаю, немного неэтично выходит - забываю благодарить=(

Я сделал такую процедуру. По CPU показывает что вызов этой процедуры занимает меньше места, чем прямое SetBounds

Procedure SetBounds21(Object1: TControl; const Left1, Top1, Width1: integer);
begin
  Object1.SetBounds(Left1, Top1, Width1, 21);
end;

Но вот вопрос - а сколько места занимает сама процедура в программе? Как вот это понять?

[phomm]

Экая зараза Вас взяла, даже сложно предположить. 99.99% что Вам надо от неё избавляться, потому как упорство и прочие качества у Вас есть, но применяете не к месту.

Вот написали Вы обёртку, она "занимает" меньше места, ну да, 4 параметра меньше 5 (в оригинальном SetBounds ещё неявный Self), на одну ассемблерную инструкцию mov сэкономили, но ведь очевидно же, что внутри неё вы всё равно раздули место - поскольку внутри вызывается сама SetBounds, а на это тоже нужны ассемблерные инструкции, или её Вы тоже будете переписывать с залезанием в приватные поля класса ?

Зачем понимать, сколько процедура занимает в программе места ? Вы микроконтроллер пишете или VCL-приложение ? Ну да, можно сказать сколько она занимает, курите ассемблер, опкоды, изучите что такое стек вызовов, что такое регистры, calling conventions, прологи-эпилоги функций. Всё это поможет посчитать сколько байтов реально занимает процедура.

Вот только на кой чёрт оно нужно, если а) по какой-либо необходимости надо добавить параметр
- и всё придётся пересчитывать и б) почти любой добавленный модуль в программе может резко увеличить размер экзешки не на байты (как в случае параметров, да и то не всегда, читайте про выравнивание по 512 байт), а на сотни кб ???

Вопросы не для ответа, а для пробивания Вашей самоуверенности в том, что такие вещи Вам нужны.
А для дзена читайте https://www.gunsmoker.ru/2013/01/opt...on-basics.html

[Vapaamies]

Сообщение от Kronos913

Но вот вопрос - а сколько места занимает сама процедура в программе? Как вот это понять?

Без сторонних инструментов — включить генерацию map-файла с номерами строк и потом ручками посчитать между нужными.

Сообщение от phomm

Зачем понимать, сколько процедура занимает в программе места ?

Чтобы прочувствовать код и потом нутром чуять, где экономия на спичках и пар в свисток, а где взаправду оптимизация?

Хотя, пример с SetBounds выглядит бредовым. Вложенные вызовы процедур ведь тоже не проходят просто так, они могут сбрасывать конвейер спекулятивного выполнения, например. В компиляторах C/C++ есть оптимизация по скорости и оптимизация по краткости кода, что не одно и то же.

Какова цель сих шаманств?

[NetSpace]

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

[Vapaamies]

Сообщение от NetSpace

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

Мы даже пересекались, и я обозначил теорию.

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

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

[Arigato]

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

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

[northener]

Сообщение от Vapaamies

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

А я нет.
Ну никак не вижу необходимости подобной "оптимизации" в прикладной программе.

[Vapaamies]

Сообщение от Vapaamies

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

Сообщение от Arigato

Объемы диска, оперативной памяти и мощности процессора позволяют об этом не задумываться.

Вспомнил анекдот про алкаша в автобусе:
— Тогда пройди вперед!

Сообщение от northener

А я нет.
Ну никак не вижу необходимости подобной "оптимизации" в прикладной программе.

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

Сообщение от Vapaamies

но старые методы не сработают

Еще раз заострюсь. Возможно, тему стоит уже разделить.