Как стать автором
Обновить

Комментарии 31

Тема очень интересная. Конечно, как .Net разработчик, я не сторонник версии «назад к истокам» и написанию программ на ассемблере или чистом C(++).
С другой стороны я тоже хотел написать подобную статью, но в несколько в другом аспекте. Проблема в том, что сейчас программы сходные по функционалу весят в десятки и сотни раз больше, чем их аналоги 10 лет назад. Взять к примеру Скайп — размер дистрибутива вырос до нескольких сотен мегабайт, хотя функционала не прибавил. То же самое и с большинством программного обеспечения и даже с веб-сайтами.
И в данном случае проблема даже не в компиляторах и в неоптимизированном коде, а в том, что в погоне за скоростью разработки подключаются фреймворки и библиотеки там, где они не нужны. Нужна простая таблица на веб-странице — подключаем в лучшем случае jqGrid или более современный аналог, в худшем — целый пакет компонентов от Telerik, Infragistics или DevExpress. И неважно что из всей их мощи вам понадобится только сортировка и постраничное отображение.

Недавно был опыт — нужно было написать веб-интерфейс для микроконтроллера (ESP8266). JQuery туда не зальёшь т.к. нет места, а доступа в интернет может и не быть. Пришлось писать на чистом JS. В результате получилась мини-библиотека весом несколько килобайт с основным функционалом JQuery (как выбор элемента по ID, навешивание классов и изменение свойств и т.д.)
Полностью согласен, очень странно видеть обычные программы которые весят нереально много…
Как и большинство, на работе, приходится использовать кучу готовых библиотек и фреймворков что бы ускорить (удешевить) разработку, хотя от мысли, сколько бесполезного кода загружается, передёргивает.

Когда пишу для себя, никогда не использую готовые библиотеки, если не понадобиться большая часть их функциональности.

Но с сайтами пол беды — многие работают более-менее нормально без JS, можно найти приемлемые сайты не заваленые кучей JS, рекламы и счётчиков. Но браузеры…

На моём стареньком ноутбуке самая большая проблема — это сёрфинг в интернете. Я могу запустить кучу программ не являющихся браузерами в том или ином виде (сами браузеры, программы на Electron и т.д), и всё будет ок, но стоит мне запустить FireFox или Chrome — ноут тихонько умирает. При этом, скачав FireFox 37 (и ранее), почувствовал как была прекрасна жизнь несколько лет назад (всё летает и ничего не тормозит), но отвалились сайты сделанные на флексбоксах и тд…
JS на микроконтроллере — это как? Где интерпретатор?
Как называется эта технология?
JS в браузере у клиента. Но хранится на микроконтроллере. От того и все ограничения.
НЛО прилетело и опубликовало эту надпись здесь
Недавно был опыт — нужно было написать веб-интерфейс для микроконтроллера (ESP8266). JQuery туда не >зальёшь т.к. нет места, а доступа в интернет может и не быть. Пришлось писать на чистом JS. В результате >получилась мини-библиотека весом несколько килобайт с основным функционалом JQuery (как выбор элемента по >ID, навешивание классов и изменение свойств и т.д.)

Насктолько не было место, что 82 килобайта не влезло (82K Jun 13 2016 static/jquery-2.0.3.min.js)?
А как туда TCP/IP влез, или он и занял все свободное метсто?

В моём случае — 512 килобайт.
Да, 82 килобайта бы влезло, но я предпочитаю использовать это место более эффективно. К примеру CSS стили прикрутить, иконки положить, больше функционала реализовать.

Без обид, но ваш комментарий — типичная логика современного разработчика, считающего, что компьютеры достаточно мощны, чтобы не считать килобайты и мегагерцы занимаемые программой.
>Без обид, но ваш комментарий — типичная логика современного разработчика
Без обид, но ваш комментарий – типичная логика «несовременных» разработчиков-одиночек любяших все держать под контроллем(мнимым). По запросу «jquery minimal» вы могли найти вагон и маленькую тележку библиотек минимального размера, вроде Zepto(~10kb, но я думаю можно вложится в 2kb или меньше, если собрать только, то что нужно). Но вы сознательно сделали все на коленке и к эффективности это не имеет никакого отношения. Если вы ставили себе целью – разобраться, то ок – но не рассказывайте про эффективность

Есть еще второй вариант – вы сделали обзор существующих решений и пришли к выводу что они не подходят, потом разработали свою уникальную библиотеку. Тогда не томите – github ждет
Скорее всего вы правы по поводу наличия микро-версий JQuery, но в данном случае мне было проще и быстрее решить задачу в лоб, чем искать и изучать аналоги.

Я не сторонник «велосипедов» (т.к. библиотеки чаще всего не содержат критических ошибок, а велосипеды — вполне могут), но и не сторонник добавления библиотек на каждый чих.
так, для понимания, к примеру у меня стек tcp/ip весит менее 16кБ в чистом виде и 24кБ с DHCP/NTP client-server/SNMP/ICMP client-server. простой web сервер — ну еще 8кБ. чистый си для AVR-а.
так, для понимания, к примеру у меня стек tcp/ip весит менее 16кБ в чистом виде и 24кБ с DHCP/NTP client-server/SNMP/ICMP client-server. простой web сервер — ну еще 8кБ. чистый си для AVR-а.

Без уточнения что выбросили и чем пожертвовали, это бесполезно "для понимания".


Например, насколько я знаю, uIP (одна из известных микро реализаций TCP/IP) не умеет
сборку фрагментированных пакетов.

Мешанина какая-то.
Ну да, драйстоуны, ветстоуны, компиляторы, интерпретаторы, байткод, кэш, code bloat — все это прекрасные слова, но зачем вы все это свалили в одну кучу и приправили жиденькими, бесполезными рекомендациями?

Рекомендации должны быть предметными, а не «вообще».

— Важна производительность именно вычислительная? Тогда — компилируемые языки, многопоточность, распаралеливание, использование GPU (OpenCL, CUDA), распределенные вычисления. У вас из всего этого — только мутноватые рассуждения о производительности и издевательские рекомендации писать на ассемблере. Издевательские — потому что современные компиляторы генерируют код весьма высокого качества, а попытки оптимизировать его вручную обычно приводят к тому, что «оптимизированная» программа работает медленнее оригинала. Кроме того, писать на ассемблере под тот же ARM — занятие для истинных гурманов.

— Важен отклик пользовательского интерфейса программы? Тогда — правильное проектирование, обработка длительных операций в отдельном потоке, и пофиг на язык программирования. Время комфортного отклика на действия пользователя — ЕМНИП, что-то около 250 миллисекунд. На такую производительность вполне способны даже весьма медленные языки программирования.

— Важен малый объем программы? Тогда — использование «легких» фреймворков, языков программирования, выдающих компактный результирующий код, и т. п.Но лично мне проблема «жира» в программах кажется слегка надуманной: на десктопных компьютерах основное ОЗУ жрут картинки и иконки, а на всяческих маломощных контроллерах обычно выбор языка программирования невелик: или пишешь на том, что предоставил производитель контроллера, или не пишешь вообще.
Ну и зачем писать бесполезные общие рекомендации, которых полно в Интернете вроде «как написать супербыструю программу на Бейсике»?! Я описал причины, а конкретные применения каждый пусть применяет к себе сам. Кроме того, см 1й абзац.
Правильный ответ
Последний же параграф — полностью ирония. Нужно просто взять серебрянную пулю и все будет хорошо

Но лично мне проблема «жира» в программах кажется слегка надуманной: на десктопных компьютерах основное ОЗУ жрут картинки и иконки
А вот это не так — достаточно сравнить программы разных версий, тот же браузер. Ну или заняться более глубоким анализом.
Я описал причины,

Да ничего вы толком не описали. Так, общие рассуждения и минимум конкретики.
Самое обидное — вы оставили за бортом самый главный вопрос: с чем боремся-то? С жЫром или с тормозами?

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

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

Вот если взять классический пример «блоатвари» — просмотрщик ACDSee, то да, была легенькая фиговинка, стал монструозный комбайн с кучей мало кому нужных функций. Но тут — опять же — возникает вопрос: так ли здесь важен язык программирования или фреймворк? Потому как гораздо важнее — решения по добавлению в программу всяческого барахла, принятые менеджерами.
Недавно смотрел тесты по скорости, разный код и оптимизиции в разы дают разницу в производительности.
Промахнулся, это ответ на комментарий zenkz.

Уверен, что объём Скайпа, как и всех других приложений ненормального размера — не от кода. Это какие-то ресурсы. Кода может быть от силы 40 МБ, и то из них 20 будут всякие таблицы для работы с Юникодом (то есть тоже не совсем код).

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


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


Ну и чего стоит название данного поста? Да лучше бы эта программа была еще толще (больше места занимала на диске), но зато простейшие текстовые меню открывала бы сразу, а не через пару минут.

Скайп — это просто пример.
Не поленился и посмотрел что из себя представляет папка со скайпом:
80 Мб библиотек и исполняемых файлов.
Топ 3:
SkypeSkylib.dll 28 Мб
Skype.exe 26 Мб
SkypeResources 15 Мб

В памяти скайп сейчас занимает скромные 28 Мб, но к нему идут ещё 2 процесса Skype Browser Host (48 + 32 Мб) Итого 100 Мб в памяти. Но это не большая проблема. Проблема в том, что он периодически грузит диск под 100% на некоторое время.
Также скайп ненавистен тем, что обновляется в самый неподходящий момент и вообще считает пользователя рабом. (Типичные ошибки современных приложений — к примеру заставлять обновляться на каждую следующую версию).

Но это ещё цветочки, т.к. те же браузеры (у меня сейчас открыто их 2 Firefox и Chrome сжирают около 2х гигов совместными усилиями — и это при 20-30 открытых вкладках)
Думаю, десятки мегабайт в этих бинарниках — тоже ресурсы.

А если учитывать то, что:
1) Скайп хранит вообще все данные в совершенно открытом виде в sqlite файлике без какой-либо защиты
2) Имеет тенденцию после пары любых "левых" жалоб блокировать аккаунт навсегда, без возможности восстановления в автоматическом режиме без участия операторов.
3) И, не знаю как, но его можно взломать, пройдя двухфакторную аутентификацию без отправки смс уведомлений (давеча сам лично столкнулся с "левыми" ссылками на гугл, рассылаемыми от всех контактов подряд).


Это говорит что-то об уровне разработчиков данного ПО. Так что не стоит учитывать скайп в 2017ом как адекватную разработку и приписывать его к "списку с примерами". Это, наверное, худшая программа, которую я встречал в жизни по всем доступным характеристикам. Ну разве что по юзабилити видел похуже.

Ваше замечание про замедление скорости реакции на щелкание мышкой мне очень понравилось.
Я давно заметил эту закономерность при переходе от 8086 -> 80286 -> 80386 -> и тд
Через месяц работы после смены системного блока я по своей реакции начинаю обгонять реакцию компьютера

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

Во-вторых, красота понятие относительное

В-третьих, ваша точка зрения будет отличаться в случаях если вы получаете ренту за обслуживание 10 серверов вместо одного, либо вы платите за эти 10 серверов вместо одного =)
Если у меня будет проект, который допустим грузит 10 машин на 100% на C#, то количество машин перестанет быть такой проблемой.
Нагрузка бэкэнда считается по пику.

А полная нагрузка Проблемой будет в любом случае.

Кстати, про 10% производительности С# в бэкэнде почти точно угадано — смотрим тут результат aspnetcore-mvc-ef
И красотой жертвовать не надо — ef это же скорее всего Enterprise Framework — все красиво, стандартно, канонически и искаропки.

Или это Вы сразу себе оправдание для шефа придумываете? =)
aspnetcore работает хуже nodejs? Серьезно? Я очень слабо в это верю

И как я понял, тут целый фреймворк сравнивается просто со стримом?

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

На самом деле надо отделять мух от котлет. Core смоделирован по подобию ноды — вебсервер(на выбор) + middleware + что-то там за ним(MVC, Nancy).
1. Есть минимум — Kestrel + Middleware. Тут node.js сильно отстает — это хорошо видно на plaintext бэнче: 1800k vs 467k.
2. Есть Kestrel + Middleware + MVC. Логично сравнивать с express — 653k vs 213k.
Это были только чистые сервер + фреймворк.

Попа начинается, когда в дело вступает зоопарк сериализаторов на .Net, из которого взяли популярной, но не самый быстрый и слегка кривенький драйвер для Npgsql. То есть к самому .Net это уже прямого отношения не имеет. Если сравнить результаты тестов, то будет видно, что при работе с базой — их производительность практически идентична и вопрос скорее всего к конкретному Data Provider.

Плюс все эти тесты проводятся на Linux. На WinServer и SqlServer было бы интересно взглянуть в тех же конфигурациях. Ну и все развивается :) Сейчас Kestrel c libuv слезет и огого что будет :D
А вы уберите EF. Он не обязателен. Причем там Npgsql, который не сказать что бы мега оптимален на Core и под Linux. Там есть косяки типа:
// postgres has problems with deadlocks when these aren't sorted
Array.Sort<World>(results, (a, b) => a.Id.CompareTo(b.Id));

Так же сериализатор надо бы на Jil, а не Newtonsoft.Json -> So I Heard Jil Is the New JSON Serializer Champion.

Просто фреймворк должен соответствовать решаемой задаче. Если вы делаете игру уровня Тетриса на Unity, то вполне заслуживаете проклятия, потому как для такой игры даже SDL многовато будет.
Если у вас сайт содержит одну только статику, а вы додумались использовать ангулярщину для эмуляции перехода по ссылкам, пользователь может и должен пинать вас ногами.
Почему так получается? Да просто большинство кодеров плотно подсело на единственный любимый фреймворк, который используется для абсолютно любого проекта — ведь в остальном же ещё разбирать надо, а тут можно начать кодить сходу. Ну да, гвозди забиваем электронным микроскопом. Зато микроскоп уже под рукой, а за молотком надо в магазин бежать.
Заметил, что не 10 лет статье было в 2016 году, а 20 лет. А скоро будет 30 :) А статья в силу сложившегося кризиса в производстве микросхем, все более актуальна…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории