1) Думаю, в процессе репостинга мы утеряли нить обсуждения.
2) Пример 1. Крупнейший негосударственный банк. Проблема: из-за обилия функционала, exe чрезмерно разросся. Решение: exe оставили маленьким, весь функционал перенесли в .bpl, каждый сотрудник подгружает только нужные ему .bpl в процессе работы.
Пример 2. Крупнейшая российская туркомпания. exe разросся до >100мб. Решение: перед выпуском, упаковывают его специальным архиватором. Всё равно, те офисы которые сидят на 3G интернете, тратят на апдейт существенное время. Это простой и потеря клиентов.
Плюс удалённой работы — можно кодить во время совещания, если не идёт ничего ценного конкретно для себя.
ОК, конкретно в случае автора, совещания бесполезны. Своим опытом избыточности совещаний я не обладаю, хотя работал в разных фирмах. Но полагаю, найдутся другие случаи в других фирмах, когда совещания полезны.
Я думал вы про оптимизацию скорости спрашиваете. И привёл соответствующий пример.
Про размер exe. Есть конторы, которые начали с простого exe с четыремя формами, а затем 15 лет не меняли архитектуры. У таких фирм exe файл уже >100мб весит, его запаковывают перед тем как отдавать пользователям. Это пример когда важен размер exe.
Я пол года назад писал на Delphi ресурсоёмкий перебор в памяти компьютера, на структурах которые в неё предварительно загружены. Из области туризма: гостиницы, пансионы, номера, трансферы, перелёты, мероприятия. Цены у всех разнятся от возрастов туристов, дней до начала тура, и так далее, в целом выходит нехилый кубик данных в ОЗУ. Пока не внедрено.
Постом выше я писал про приоритет размера exe, этот вариант хуже. Впрочем, я могу ошибаться.
По моим сведениям 10-летней давности, case выигрывает по скорости у if, если вариантов много и аргумент это byte либо перечисляемый с <=256 вариантов. Для размеров exe, case не полезен.
Это зависит от того, требуется ли Undo пользователю, если да то можно при числе слоёв больше трёх хранить в последнем слое снимок наложения всех предыдущих.
Я специально указал что это локальная переменная, а не property (который может ресурсоёмко присваивать значения и / или перерисовывать интерфейс и / или дёргать внешние методы, если на присвоение повесить процедуру, которая это делает). Был бы property — была бы другая реализация.
Очевидно, что действия по жарке стейка из морозилки и из живой коровы — это разные действия. Плох тот повар, который в обоих случаях действует одинаково.
P.S. Не знаю что такое clang-format, в Delphi есть Ctrl+D — автоформатирование.
Видя название переменной Font_Color, несложно догадаться что это интерфейс, а не таймкритичная секция. Значит экономим размер exe, а не скорость. Кстати я сильно не уверен что ваш способ экономит скорость.
Уменьшение количества строк кода приводит, как минимум, к большему функционалу на одном экране. Уменьшение количества команд — и к тому что проще читать, и к тому что меньше ошибок.
Прошёл по вашей ссылке, там такие строки:
var mat_product_symbolic = B => `(a,b)=>[${reshape(range(16),4).map(c=>B[0].map((_,i)=> B.reduce((s,d,j)=>`${s}+b[${d[i]}]*a[${c[j]}]`,0))).flat()}]`;
У автора этих строк, очевидно, не стояло задачи, чтобы их было легко читать.
Большее количество команд (вы всё взяли в begin-end, плюс добавили ненужные else) приводит к повышению вероятности ошибок, о чём я говорил выше.
Вот и вы внесли две ошибки — забыли написать два end.
Из написанного мной сегодня.
Код до моих правок (плохой код):
if FPriceSet.CurrentOverrideSPOID > 0 then
i := cont.IndexOverrideSPOByID(FPriceSet.CurrentOverrideSPOID)
else
i := 0;
if i > 0 then
begin
Delta := cont.Price - cont.OverrideContainers[i].Price;
if Delta > 0 Then
Font_Color := clRed
else
if Delta < 0 Then
Font_Color := clBlue
else
Font_Color := clOlive;
end;
Код после моих правок (хороший код):
if FPriceSet.CurrentOverrideSPOID > 0 then
begin
i := cont.IndexOvrSPOByID(FPriceSet.CurrentOverrideSPOID,IsY);
if i > 0 then
begin
Delta := cont.Price - cont.OvrContainers(i,IsY).Price;
Font_Color := clOlive;
if Delta > 0 Then Font_Color := clRed;
if Delta < 0 Then Font_Color := clBlue;
end;
end;
Значение переменной i ниже данного фрагмента не используется, Font_Color и i — локальные переменные.
Что касается ООП-баталий в комментариях к этой теме.
Помните! Производительность программиста в день, и количество ошибок на количество строк, от языка программирования не зависит! Умножая объём текста, вы умножаете количество багов.
На вопрос (1):
1) Конечно, невозможность добавить изображение через сайт (вернее, добавить — то можно — есть страница для авторов, но оно не появится в системе до следующего апдейта) — это плохо.
2) Рассматривалась возможность предоставления сайта на флешке, во варианте как сетевого так и локального использования по желанию пользователя
На вопрос (2):
Вы говорите про Яндекс.Облако? Поиск по словам «S3-like Яндекс» привёл меня на него.
Вот тарифы: cloud.yandex.ru/prices
Предельный размер диска = 4ГБ, по цене 8750 рублей в месяц.
Это что за цены/объёмы из 1990х годов?
На вопрос (3):
1) PHP просто не справится со обработкой картинок типа 7000х10000. Линуксовая виртуалка (или что там у хостинга стоит) для этого просто не предназначена
2) Тормоза пользователю, особенно в некоторых папках
3) Трата процессорных ресурсов сервера, за которую сайт в определённый момент просто автоотключат
4) Процесс создания миниатюр на локальной машине даёт не 100%, но всё же гарантию, что картинки не стали битыми из-за каких-нибудь глюков HDD
5) Мне нужен не просто скейлинг абы какой, а качественный скейлинг. Для этого используется библиотека Graphics32
6) В процессе создания миниатюр система выявляет неверные расширения файлов — .jpg вместо .png и наоборот, в основном.
Почему спотыкается? Разве волны моря не могут разрушить дамбу?
Можно конкретный пример, на котором фотоэффект не может быть объяснён волновой теорией?
2) Пример 1. Крупнейший негосударственный банк. Проблема: из-за обилия функционала, exe чрезмерно разросся. Решение: exe оставили маленьким, весь функционал перенесли в .bpl, каждый сотрудник подгружает только нужные ему .bpl в процессе работы.
Пример 2. Крупнейшая российская туркомпания. exe разросся до >100мб. Решение: перед выпуском, упаковывают его специальным архиватором. Всё равно, те офисы которые сидят на 3G интернете, тратят на апдейт существенное время. Это простой и потеря клиентов.
ОК, конкретно в случае автора, совещания бесполезны. Своим опытом избыточности совещаний я не обладаю, хотя работал в разных фирмах. Но полагаю, найдутся другие случаи в других фирмах, когда совещания полезны.
Про размер exe. Есть конторы, которые начали с простого exe с четыремя формами, а затем 15 лет не меняли архитектуры. У таких фирм exe файл уже >100мб весит, его запаковывают перед тем как отдавать пользователям. Это пример когда важен размер exe.
По моим сведениям 10-летней давности, case выигрывает по скорости у if, если вариантов много и аргумент это byte либо перечисляемый с <=256 вариантов. Для размеров exe, case не полезен.
Это ленивые члены команды навешивают на эффективных ярлык токсичного.
Очевидно, что действия по жарке стейка из морозилки и из живой коровы — это разные действия. Плох тот повар, который в обоих случаях действует одинаково.
P.S. Не знаю что такое clang-format, в Delphi есть Ctrl+D — автоформатирование.
Прошёл по вашей ссылке, там такие строки:
У автора этих строк, очевидно, не стояло задачи, чтобы их было легко читать.
Вот и вы внесли две ошибки — забыли написать два end.
А для чего здесь лишние else?
1) Количеством машинных команд, которые добавляются в exe файл.
2) Количеством строк исходника
Код до моих правок (плохой код):
Код после моих правок (хороший код):
Значение переменной i ниже данного фрагмента не используется, Font_Color и i — локальные переменные.
Что касается ООП-баталий в комментариях к этой теме.
Помните! Производительность программиста в день, и количество ошибок на количество строк, от языка программирования не зависит! Умножая объём текста, вы умножаете количество багов.
1) Конечно, невозможность добавить изображение через сайт (вернее, добавить — то можно — есть страница для авторов, но оно не появится в системе до следующего апдейта) — это плохо.
2) Рассматривалась возможность предоставления сайта на флешке, во варианте как сетевого так и локального использования по желанию пользователя
На вопрос (2):
Вы говорите про Яндекс.Облако? Поиск по словам «S3-like Яндекс» привёл меня на него.
Вот тарифы: cloud.yandex.ru/prices
Предельный размер диска = 4ГБ, по цене 8750 рублей в месяц.
Это что за цены/объёмы из 1990х годов?
1) PHP просто не справится со обработкой картинок типа 7000х10000. Линуксовая виртуалка (или что там у хостинга стоит) для этого просто не предназначена
2) Тормоза пользователю, особенно в некоторых папках
3) Трата процессорных ресурсов сервера, за которую сайт в определённый момент просто автоотключат
4) Процесс создания миниатюр на локальной машине даёт не 100%, но всё же гарантию, что картинки не стали битыми из-за каких-нибудь глюков HDD
5) Мне нужен не просто скейлинг абы какой, а качественный скейлинг. Для этого используется библиотека Graphics32
6) В процессе создания миниатюр система выявляет неверные расширения файлов — .jpg вместо .png и наоборот, в основном.