Экономия
раскрыть ветку (9)
раскрыть ветку (1)
Я стараюсь не считать всех вокруг идиотами по умолчанию, а стараюсь понять причину странного поведения. Но таки да, чаще оказывается, что если человек творит херню - он идиот)
раскрыть ветку (6)
У вас можно было чрз проходную таскать носители информации??
у нас за аудиокассеты до сих пор взъебут
у нас за аудиокассеты до сих пор взъебут
раскрыть ветку (3)
Можно потроллить службу охраны. Купить на барахолке какой-нибудь Jazz-диск и попробовать его пронести туда-сюда, чтобы нашли. А потом пусть думают, как его прочитать, чтобы доказать, что ты вынес ценную информацию.
раскрыть ветку (2)
Не вопрос, можно троллить досхочу. Факт нарушения - уже штраф из зп и немалый, а если найдется чего - досвидос.
У нас на заводе один мастер занёс крепёж для кабеля,тот что гвоздиком к стене пробивается. Так когда он остатки выносил(штук 10 в пакетике),его повязали на проходной и составили протокол о краже.Так его за это чуть не уволили,еле доказал что он не вор.
Ага, а за дискету ничего не будет.
И дисководы там есть, ну.
В режимных конторах системник в кейсе, там только кнопка питания доступна. и провода торчат. Никаких дисководов, сидюков и, тем более, USB. И интернета нет. Только локалка, куда информация и скидывается.
раскрыть ветку (1)
раскрыть ветку (1)
Тогда интернет не был в каждом утюге, начало нулевых как-никак. Мужик, вроде немолодой был, да и я не был с ним лично знаком, так что подробностей такого фетиша не знаю.Мопед не мой, я просто разместил объявление
😀
Если копировать ежедневно исходники на дискету, то на 3-4 месяце использования информация на дискете скажет "привет, хочешь поебаться по-настоящему?".
раскрыть ветку (1)
А я ещё "Пылдинг" помню. Информатика в школе была... рисовали в тетрадках схемы из ромбиков, квадратиков и тд, пытались расшифровывать код 01, играли в змейку и ящики на компе.. даже перфокарты нам показывали... эх, давно это было..
не сразу понял, что два комментария выше - стеб, так как от прочтения пукан перегревался, и мозг в защиту ушел.
-Пушить всегда в мастер, не разводим кучу веток и не путаем вечными коммитами;
- Новые классы вообще можно не создавать, все в одном писать, ооп вообще бред для того, чтобы погромисты много денег получали;
- зачем делать много таблиц, когда можно сделать одну большую со всеми записями в одной бд
- Новые классы вообще можно не создавать, все в одном писать, ооп вообще бред для того, чтобы погромисты много денег получали;
- зачем делать много таблиц, когда можно сделать одну большую со всеми записями в одной бд
раскрыть ветку (28)
Бери выше: одну бд под все нужды организации! Туда и сайт и бухгалтерию и проходы с турникетов… а ну и чтобы она одновременно была и тестом и продом)
раскрыть ветку (14)
раскрыть ветку (3)
раскрыть ветку (2)
Да, просто добавить флаг IsTest, по нему записи и разделять. Хотя, не, лучше флаг IsProdOrTest, чтобы ещё понятнее.
раскрыть ветку (1)
Порвало со смеху
Представил, как в одной записи в БД содержится в начале бухгалтерская инфа, а в конце - время выхода с работы
Какой ад!
раскрыть ветку (1)
Всё верно, ООП - это происки вредителей и лентяев, функций и структур хватит всем.
Пушить в мастер (ой, извините, в мейн) отличный способ дать всем разработчикам шанс ознакомиться с самыми передовыми фишечками программы сразу же! Кисель с ветками разводят только неуверенные в себе новички.
раскрыть ветку (1)
-Пушить всегда в мастер, не разводим кучу веток и не путаем вечными коммитами;ты не будешь путаться с коммитами если сосквошишь их в 1
раскрыть ветку (1)
Не понимаю этой дрочки на ООП. Весьма специфическая парадигма, нормально используемая только в бизнес-логике. Функционалка будет гораздо универсальней.
- Не писать ни UnitTests ни IntegrationTests. Они только раздувают размер исходников.
- Не писать комментарии к коммитам.
- Не писать комментарии к коммитам.
раскрыть ветку (1)
Про таблицы это что-то на NoSQL-ном?
Я когда-то давно решил попробовать NoSQL и чуть не проблевался. Единственное, что понравилось, это json формат.
Я когда-то давно решил попробовать NoSQL и чуть не проблевался. Единственное, что понравилось, это json формат.
раскрыть ветку (1)
Про таблицы это как раз на SQL-ном. В NoSQL структура может быть абсолютно любой. У нас, например, в проекте дерево объектов. В ряде задач производительность не то что на порядок, а на порядок порядков выше, чем с реляционной БД. Естественно, можно было бы пользовать секционирование и пр. Но эффект все равно не тот. Если нужно хранить очень дофига (около миллиарда) небольших разрозненных записей, NoSQL подходит куда лучше.
раскрыть ветку (17)
Компилятор все равно все пробелы, пустые строки, комменты, неиспользуемые переменные вырезает
раскрыть ветку (14)
раскрыть ветку (7)
раскрыть ветку (6)
Все, что компилируется в байт-код (JVM, .NET) сохраняет названия классов, методов, полей. Рефлекшн же.
раскрыть ветку (1)
раскрыть ветку (4)
Какой? Тут от языка зависит. Например тот же пхп. Официально это интерпретируемый язык... Но на самом деле он комплируемый. Просто комплируется налету
раскрыть ветку (3)
Помню по молодости работал в одном PHP-проекте. Это был очень известный интернет-магазин. Там был просто огромный главный файл (уже не помню как он называется. Что-то вроде аналога Global.asax в шарпе.). И вот вместо того, чтобы его как-то оптимизировать, разбивать. Решили проблему просто: удалить все комменты!!!
И это помогло. Сайт ускорился процентов на 10-20.
Правда говнокод стал уж совсем нечитаем...
Сейчас бы мне за такую работу руки бы поотрывали. А тогда вся контора так работала.
Пфф, Херня все это.Вот на спектруме программисты чудеса творили. Я ставил себе дизассемблер, разбирал код игр, вместо того что-бы играть и тихо млел...
На хер писать свой код, в ПЗУ уже всё за нас написано...просто обращаемся к нужным кускам кода в любых подпрограммах.
Не хватает оперативы - распаковываем код игры прямо в экранную память, а получившееся артефакты обыгрываем в геймплее)))
А вы тут про пробелы какие то...
На хер писать свой код, в ПЗУ уже всё за нас написано...просто обращаемся к нужным кускам кода в любых подпрограммах.
Не хватает оперативы - распаковываем код игры прямо в экранную память, а получившееся артефакты обыгрываем в геймплее)))
А вы тут про пробелы какие то...
раскрыть ветку (2)
Использование ПЗУ, это обязаловка при работе с TR-DOS. Помнится свой драйверок писал, попарился.
раскрыть ветку (7)
А чтобы с экономить место в своей квартире: можно жить в квартире соседа! Тоже отличная идея
раскрыть ветку (6)
раскрыть ветку (5)
Да там нива непаханная: коммуналка, машина, тапки... В отпуск по его путёвке.
Главное, чтоб сосед похороны не затеял.
Главное, чтоб сосед похороны не затеял.
раскрыть ветку (2)
Подбирая символы для переменной, нужно старатся использовать те, в байтах которых меньше битов-единиц. Так ещё и электроэнергию сэкономить можно.
Используйте десятки goto и переброску 16-битных переменных с получением их адреса, приведению к указателю на 8-битную переменную, модификацию и разыменование.
Важный момент -- тестирование надо провести сразу, пока еще не улетучилось понимание логики кода, если это понимание вообще было.
p.s. а на самом деле я не уверена, что даже на ассемблере смогу написать быстрее. Максимум тактов 5-15 сэкономлю. Ассемблерный листинг -- это просто квинтэссенция всех оргазмов с чистейшими слезами девственных ангелок.
Но изначально было почти 500 тактов. И это вообще-то было достаточно, ибо предел был 800 тактов.
p.p.s. а вообще пост наверно про WEB программеров, которые не знаю про компрессоры кода)
раскрыть ветку (11)
А почему тут не цикл с сравнением newVALp со значением из массива? И ведь goto даже не понадобится 😅
раскрыть ветку (3)
Ну человек хотел оптимизировать по скорости. Цикл уменьшит производительность этого участка в 5-8раз, ибо надо делать 2 условных перехода, модификацию индекса. И к тому же адрес обращения в условии будет не по статическим адресам, а динамическим, его рассчитывать надо, это сразу плюс 5-6 тактов минимум за каждое обращение.
Переброска 16-бит переменных с динамическим адресом(через адрес в регистре ядра) будет занимать не 2 такта, как со статическим, а 4 такта. Если повезёт и компилятор додумается правильно использовать единственные 2 регистра, в которых можно размещать адреса
Это только то, что мне спросонья пришло в голову, ещё даже из кровати не вылезла, если подумать, будет ещё хуже.
В общем циклы и динамические адреса это чудовищно неэффективно с точки зрения проц. времени.
раскрыть ветку (1)
Для скорости. Это похоже на сильно оптимизированный код для какой-то маленькой железки, и он должен переводиться строго определённым образом.
раскрыть ветку (1)
Просто некоторые из них не знают, что есть компрессоры, и что соответственно нет смысла экономить на отступах)
раскрыть ветку (9)
Всё ещё видим в кошмарах. Не так страшен ассемблер, как педагоги, признающие написание кода только в блокноте. Бумажном.
раскрыть ветку (1)
- Пиши весь код в 1 строку (если яп позволяет) и без пробелов, где позволено, ещё одна просто сумасшедшая экономия.Так компилятор C++ и так так воспринимает код, ты хоть измаж его пробелами (не считая текста), отступами, переносами, ему пох, он это все не видит и память это не занимает, просто одна монолитная строчка.
С 3 символами - забыли цифры и спецсимволы типа подчеркивание, так что до 400.000+ вариантов довести можно
+ при выборе типа выбирать тот, что короче в названии, если он подходит для задачи
раскрыть ветку (5)
раскрыть ветку (4)
И как эту ... "Не аппетитную субстанцию" читать? Это как САПР для разработки схемотехники имеющий в себя простенькие возможности для изнасилования логических конструкций/циклов, и пидорас-схемотехник, после разработки схемы её оптимизирует в отдельные элементы (каждый в одном экземпляре), а дальше разруливает внешней логикой. И в итоге эта ёбанная мешанина в режиме моделирования работпет, а как её прочитать - хрен его знает
А разве нет минификаторов, которые код делают в одну строку без оступов и комиентариев? Пишешь человеческий код, а потом одной кнопкой делаешь его легким.
раскрыть ветку (6)
Хотел минуснуть, а потом перехотел. Если не понял, то: это липовые оптимизации, которые не приносят профита, но приносят гемор. Если понял, то это очень толсто, бро.
раскрыть ветку (4)
писать во всю ширину монитора, не переходя на новую строку.
такой код выглядит аккуратно, монолитно и впечатляюще.
раскрыть ветку (2)
Тогда, для экономии памяти, предлагаю поставить в ряд, моников 10, широкоформатников. Можно целыми классами хуячить в одну строку. Я прав, я прав?
раскрыть ветку (1)
раскрыть ветку (1)
пояснять надо, что это конкурс. А то пугливая молодежь как бы не подумала, что новый стандарт ))
Какая компилятору разница, сколько там пробелов и какая длина переменных. Если имеется в виду js, то для этого есть gulp.
совершенно лишне заниматься этим всем самостоятельно: запустив обфускатор перед релизной компиляцией можно добиться точно такого же эффекта.
Только использование табов вместо пробелов (и наоборот) не влияет на читаемость кода в большинстве случаев, в отличие от ваших советов)
Игры для спектрумов и коммодоров до сих пор пишут, там даже есть соревновательная дисциплина "16 килобайт". Это не нубские 48 килобайт, тут надо оптимизировать!!!
раскрыть ветку (3)
раскрыть ветку (2)
Кузнечика узнал, но за такие табы надо бить по рукам. Почему начинается не с затакта? Где ритмической рисунок? Что за нелепый размер?
раскрыть ветку (1)
Нахрена оптимизировать. Пусть покупают себе мощнее оборудование и "толще" кабель. Так мне недавно намекнули, когда я заикнулся про оптимизацию и загнали в минуса.
раскрыть ветку (17)
И правильно сделали, подозреваю. Оптимизация - крайне дорогое удовольствие, за которое ни потребитель, ни заказчик обычно платить не готовы. А раз так - нахрен она и не нужна в значительном числе случаев
раскрыть ветку (16)
Иногда выбор в другом.
Есть устройство, которое передаёт данные по очень компактном протоколу. Либо мы впихиваемся в оставшиеся в протоколе 2 резервных байта, либо переходим на другой протокол теряя совместимость.
раскрыть ветку (1)
Ну это и не та оптимизация, о которой идет речь) Понятно, что всегда есть какие-то условия, в которые надо влезть. В том числе и по производительности, памяти, скорости. Но это не значит, что после того, как в эти условия влезли - надо продолжать оптимизацию, не так ли?
раскрыть ветку (13)
Не, бекэндер, в том числе хайлоад систем. Просто оптимизация - это действительно ОЧЕНЬ дорого. Те же игры вы готовы покупать за х10 их цены? Вряд ли. Поэтому никто не будет этим заниматься.
раскрыть ветку (12)
Ну всё же запустить провайдер и оптимизировать самый жыр обычно много времени не требует, в игрушках во всяком случае,в highload там всё сложнее конечно.
раскрыть ветку (3)
Ну, игрушки я почти не писал, но предполагаю, что и там не так все просто:
1) архитектура решения может просто не позволять это сделать
2) оптимизация всегда сложнее просто написания кода, то есть требует более толковых спецов (а это больше денег)
3) оптимизация часто ухудшает читаемость и поддерживаемость кода, а это дополнительные затраты на всю дальнейшую работу от онбордингов до требований к разрабам и скорости внесения правок и реализации новых фич
4) оптимизация - это всегда дополнительное тестирование по итогам, как тестирование производительности, так и функциональные тесты - а это деньги
5) оптимизация - это работа, то есть тратится время разрабов (причем самых топовых, кто сможет этим заниматься эффективно) и время лида, который будет проверять весьма непростые изменения. Время - снова деньги
6) можно еще кучу таких же пунктов написать и все они будут сводиться к одному: ее не делают не потому, что не могут. Ее не делают потому, что это очень дорого
раскрыть ветку (2)
Это да, я скорее о багах влияющих на оптимизацию. Как пример у нас было: сильно просел фпс на одном из дисплеев на ~30% примерно, начали искать, нашли цикл на 1000000 проходов который не возвращает никаких результатов работы, но запускается при отрисовке каждого кадра. Человек что-то отлаживал и забыл убрать за собой. Или вот тестовое задание проверял: запись в файл результатов работы программы, а там запись побайтово и flush после каждого байта.
При наличии профайлера такие вещи находятся довольно быстро и фиксятся за 3 секунды. Зачастую сильно повышая производительность, и таких вот багов, я уверен, можно найти много. А если для оптимизации требуется архитектуру пересматривать, то тут да, дорого и нахрен никому не упёрлось.
При наличии профайлера такие вещи находятся довольно быстро и фиксятся за 3 секунды. Зачастую сильно повышая производительность, и таких вот багов, я уверен, можно найти много. А если для оптимизации требуется архитектуру пересматривать, то тут да, дорого и нахрен никому не упёрлось.
раскрыть ветку (1)
Ну, во-первых, такие вещи не должны проходить код-ревью перед мерджем каждого пулл-реквеста )
Но тут соглашусь - такие штуки надо фиксить, это действительно скорее именно баги, чем оптимизация. Но это в более-менее приличных командах достаточно редкие случаи.
Более того, иногда даже можно делать и полноценную оптимизацию, просто надо понимать как и, главное, зачем ее делать. Если есть какие-то критичные пути исполнения, которые прямо влияют на те или иные затраты или критичны для исполнения - тут, конечно, придется стряхивать пыль с профайлера, метрик и логов и начинать копаться )
Не надо тут мне тухляк свой гнать. Раньше всё прекрасно оптимизировали под слабые системы и цены были конкурентоспособные. А тут вдруг в 10 раз, с какого хера? Твои доводы говно и популизм для школьников.
А сейчас даже в сраном плеймаркете ОБЫЧНЫЙ КАЛЬКУЛЯТОР весит 20-40 МЕГАБАЙТ блять нахуй!!!! Какого хуя? Что блять туда засунули?)
Не без труда мне удалось найти калькулятор весом 200 КИЛОБАЙТ, так он еще и оказался инженерным.
Просто вы, программисты, ленивые, тупые жопы. И оправдания у вас такие же)
раскрыть ветку (1)
Мои доводы - это больше 12 лет опыта работы в индустрии. А твои? Все сговорились быть ленивыми и специально кодить плохо?)
В калькулятор засунули какой-нить фреймворк, который обеспечивает 90% от его фоновой функциональности и взаимодействия с окружением. И ускоряет его разработку в десятки и сотни раз (ну, конечно, с учетом, что калькуляторы делают сейчас в основном какие-нить джуны ради опыта, а реальное ускорение от фреймворка будет чувствоваться на более масштабных приложениях).
А так - приложения становятся сложнее, реализации требуются все быстрее, нагрузки растут чуть не по экспоненте. Невозможно это одновременно и создавать и оптимизировать. Можешь хейтить это как угодно, но это диктуется банальными законами экономики - потребитель хочет быстрее и дешевле. И плевать ему на оптимизацию. Так что - сами виноваты, что хаваете - то и разрабатываем.
Тупиковая ветвь развития информационной технологии, как и колесо. Каждый раз одни и те же грабли. Уже не смешно)
раскрыть ветку (5)
Если вы считаете, что оптимизация важна и будет окупаться - никто не мешает вам выпускать свои вылизанные до работы на калькуляторах продукты и забирать рынок у "неэффективных" продуктов без оптимизации. Пока же экономика показывает, что оптимизация не нужна никому - ни потребителю, ни производителю
раскрыть ветку (4)
Если честно, какое-то крайне нелепое утрирование. Всё таки есть какие-то промежуточные состояния от "от оптимизация не нужна нигде никому" и "все продукты выходят в вылизанном до идеала состоянии". Я уж молчу про то, что любая оптимизация - якобы обязательно жутко дорого. Есть реальные проекты, где существующую систему ускорили в разы, просто заменив неэффективную структуру данных более производительной, потому что до этого об этом никто не подумал или это было не критично на момент разработки. И порой подобное делают вообще студенты в рамках стажировки.
раскрыть ветку (1)
Оптимизация всегда делается по минимально необходимому уровню. Как только производительность укладывается в достаточный коммерчески требуемый уровень - все, процесс останавливается.
Оптимизация - это всегда ОЧЕНЬ дорого в реальных проектах. А если вы приводите в пример какие-то проекты - приводите и затраты на это, причем в соотношении с прибылями. Даже из ваших куцых слов понятно, что кто-то занимался этой самой заменой структуры данных, проверял, замерял итоги, проводил редеплоймент. А это все деньги. Но почему-то вы не приводите данные о том, сколько выгоды получили эти проекты от этой оптимизации (и была ли она). А ведь это главный вопрос в теме )
Если ваш проект могут улучшить студенты в рамках стажировки - можете вообще мои слова к своим проектам не применять. Я говорю уже о достаточно сложных и развитых проектах, а не о приложениях из полутора строк кода и крошек в клавиатуре.
Вообще, у вас какая-то проф деформация, наверное, из-за своей сферы программного обеспечения, потому что естественно оптимизация очень много где играет решающую роль. Игры - самый простой и банальный пример. В чём смысл делать игру, если её видеокарты не потянут? А чем меньше ресурсов жрёт игра, тем больше людей смогут установить игру на свой компьютер, тем больше людей в неё смогут играть, тем больше у разработчика прибыль. А уж как разрабатываются игры под консоли - тихий ужас оптимизаторов. Но это всё не значит, что разрабы будут до посинения оптимизировать каждую строчку кода, но вполне естественные ограничения на производительность будут в любом случае. И оптимизация - очень большая часть разработки почти любой крупной игры.
раскрыть ветку (1)
В чём смысл делать игру, если её видеокарты не потянут?
Смысл в том, чтобы сделать игру, которую потянет достаточное число видеокарт, а не заниматься оптимизацией ради оптимизации дальше.
А чем меньше ресурсов жрёт игра, тем больше людей смогут установить игру на свой компьютер, тем больше людей в неё смогут играть, тем больше у разработчика прибыль
Это не так работает) Вернее, это работает только до определенного уровня видеокарт, после которого затраты на оптимизацию станут перевешивать число потенциальных покупателей (читай - прибыли). Поэтому всегда ставится планка типа "вот это мы еще поддерживаем, а все что менее производительное - нам не интересно, они все равно не купят достаточно копий".
А вы рассуждаете очень наивно, без учета этих самых простейших расчетов.
И оптимизация - очень большая часть разработки почти любой крупной игры.
Да кто бы спорил. Но, заметьте, не просто оптимизация, а минимально достаточная. Если игра уже работает на нужном железе - никто не будет ее вылизывать дальше. Это просто никому не нужно - ни игрокам, ни разработчикам. А тут народ ратует за оптимизацию ради самой мифической оптимизации
- Пиши весь код в 1 строку (если яп позволяет) и без пробелов, где позволено, ещё одна просто сумасшедшая экономия.Если код заливать на какой-то микроконтролер разве не лучше сделать версию без пробелов, что бы вместить (в байтах) больше кода?
Кажется я понял почему исходники крупных сайтов , гугл и инет магазинов, все почти в 1 строчку. Плюс ко всему хрен разберёшь код.
раскрыть ветку (2)
раскрыть ветку (1)
Ебать вы все умные. У меня в контекстном фокса меню это называется - исходный код страницы.
Само собой это не сам исходник сайта!
Само собой это не сам исходник сайта!
Все это справедливо только для яп где код исполняется на лету (java и прочее). Для всего остального когда на выходе исполняемый файл (библиотека) это значения не имеет.
раскрыть ветку (1)
Java транслируется в байт-код, а ещё этот байт-код можно запихнуть в jar-файл и отдать заказчику (по сути тоже самое, что и библиотека). Так что с такой точки зрения Java тоже пофиг на все эти оптимизации. Вот только, обычно люди всё-таки хранят исходники, и даже заливают их на сервера, гит и прочее.
P.S. А ещё это всё шутки, в 2021 году нет смысла париться о размере исходников засчёт пустых строк и отступов.
ещё комментарии
Юмор со всего света
5.1K пост9K подписчика