В мире С# вполне клёво. NetCore с каждым новым релизом оптимизируют, и об этом пишут в нвостях релиза. Вполне реально улучшать не только функционал, но и скорость функционала, как старого, так и нового.
Шероховатости есть. Если на хабре не запрещено, улучшение статьи. То подредактирую. Сам когда перечитываю, понимаю, что в некоторых местах можно сделать лучше. Требует доработок.
Дабл так же отъедает озу при просмотре картинок, ну да. И если открыть тыщи картинок, то и проц нагрузит и озу. Это нормально. Так как задача требует. Но если закрыть показ картинок, потребление вернется обратно. Но когда на старте 128 метров и показывает просто каталоги с файлами. Чёт фигня..
Оптимизация != оптимизированного вусмерть кода. Это и выбор алгоритмов, и уменьшение объема данных и т.д Это не то байтоложество с ассемблером. (уверен в прикладном софте это не нужно)
Понятно, что бабло решает. Но это не значит, что это здраво, логично и является истинной, потому что бабло. Абсурд хоть и дорогой, остается абсурдом.
Опять же в линуксе есть выбор. Ставь любые среды, жрущие, средне жрущие, люто жрющие. Общая температура в норме. Но в душе почему то закрадывается сомнение, что требования Dolphin, сопоставимы с его возможностями.
Если делать аналогию с дверью, то у вас она бы весила пару тон и открывалась с помощью пульта, находящимся под землей на глубине 2 км. Представьте сколько нужно совершить ействий, что бы открыть дверь. И цену удобства и всей инфраструктуры. Понятно, что функционал позволяет это сделать. Но какой ценой. Строители юзают такой фреймворк. Зато быстро, у них отлажен процесс, уже есть скалды с дверями и т.д
Вилка и ложка. Улучшать уже не куда)) Я за стремление к балансу. Функционал софта, должен соответствовать его требованиям к железу.
utf8 золотая середина. Текст не тормозит сам по себе. Что бы вывести пару тысяч знаков utf8 требуются нано-нано-секунды. Условно 0. Но что бы это вывести на среднем сайте нужно 1000. Ну вы поняли.
В мире линукса, данные проблемы решаются. Есть как маленькие, так и большие кроссплатформенные фреймворки. Как вариант Qt уже на микроконтроллеры портировали, понятно что жирные микроконтролеры. Но в сотни раз слабее текущих ПК. Данные задачи решаемы. Это не какая то теория требующая доказательств. Наработки все есть.
Уверен, что в больших компаниях, с сотней эффективных менеджеров в красивых и дорогих пиджаках, лучше знают как решать данные проблемы. Лично я, как минимум выделил команду на оптимизацию самого прожорливого и тормозящего кода. Windows используют на сотнях миллионах устройств. Насчет выхлопа в доходе сказать затрудняюсь, так как каждая доработка и изменение исчисляется в конкретном кол-ве валюты. С другой стороны, тормозяший функционал, кто то написал, и функционал прошел приемку. Не озаботившись, как оно будет работать у сотен миллионов пользователей, с ввполне хорошим и современным железом. Это вариант идеальный.
Насчет реалистичного, затруднюсь ответить, я разработчик. Обычно на текущей работе создают задачи по оптимизации функционала, и это приносит прибыль. Я уже понял ваш хитрый вопрос. Своим ответом я на него и ответил. Причина доход\расход.
В мире С# вполне клёво. NetCore с каждым новым релизом оптимизируют, и об этом пишут в нвостях релиза. Вполне реально улучшать не только функционал, но и скорость функционала, как старого, так и нового.
Унификация на utf8 это капля в море. Не в utf8 проблема.
Шероховатости есть. Если на хабре не запрещено, улучшение статьи. То подредактирую. Сам когда перечитываю, понимаю, что в некоторых местах можно сделать лучше. Требует доработок.
Дабл так же отъедает озу при просмотре картинок, ну да. И если открыть тыщи картинок, то и проц нагрузит и озу. Это нормально. Так как задача требует. Но если закрыть показ картинок, потребление вернется обратно. Но когда на старте 128 метров и показывает просто каталоги с файлами. Чёт фигня..
Оптимизация != оптимизированного вусмерть кода. Это и выбор алгоритмов, и уменьшение объема данных и т.д Это не то байтоложество с ассемблером. (уверен в прикладном софте это не нужно)
Понятно, что бабло решает. Но это не значит, что это здраво, логично и является истинной, потому что бабло. Абсурд хоть и дорогой, остается абсурдом.
Дабы закрыть гештальт с калькуляторами, выбрал калькулятор программист
Самый прожорливый
Инженерный побольше требует памти
Жрет не жрет, будет зависить от сравнения. Если сравнивать с электрон, то потребление 0. Если с Windows 95...
Linux + Wine?
Lubuntu 300 мб на старте. Летает.
Раньше выводили, текст, выводили окошки. А теперь тоже самое требует лярды инструкций, подозрительно.
Опять же в линуксе есть выбор. Ставь любые среды, жрущие, средне жрущие, люто жрющие. Общая температура в норме. Но в душе почему то закрадывается сомнение, что требования Dolphin, сопоставимы с его возможностями.
Не показатель
Уверен не меньше функционала содержит.
Если делать аналогию с дверью, то у вас она бы весила пару тон и открывалась с помощью пульта, находящимся под землей на глубине 2 км. Представьте сколько нужно совершить ействий, что бы открыть дверь. И цену удобства и всей инфраструктуры. Понятно, что функционал позволяет это сделать. Но какой ценой. Строители юзают такой фреймворк. Зато быстро, у них отлажен процесс, уже есть скалды с дверями и т.д
Вилка и ложка. Улучшать уже не куда)) Я за стремление к балансу. Функционал софта, должен соответствовать его требованиям к железу.
utf8 золотая середина. Текст не тормозит сам по себе. Что бы вывести пару тысяч знаков utf8 требуются нано-нано-секунды. Условно 0. Но что бы это вывести на среднем сайте нужно 1000. Ну вы поняли.
В мире линукса, данные проблемы решаются. Есть как маленькие, так и большие кроссплатформенные фреймворки. Как вариант Qt уже на микроконтроллеры портировали, понятно что жирные микроконтролеры. Но в сотни раз слабее текущих ПК. Данные задачи решаемы. Это не какая то теория требующая доказательств. Наработки все есть.
Согласен. Но положение удручает. Представьте сколько сотен миллионов ПК просто так греют воздух. Эх...
Советуете ставить сборку ZverEditionLite? Я по многочисленным мануалам отключал службы. Вроде лучше стало.
Уверен, что в больших компаниях, с сотней эффективных менеджеров в красивых и дорогих пиджаках, лучше знают как решать данные проблемы. Лично я, как минимум выделил команду на оптимизацию самого прожорливого и тормозящего кода. Windows используют на сотнях миллионах устройств. Насчет выхлопа в доходе сказать затрудняюсь, так как каждая доработка и изменение исчисляется в конкретном кол-ве валюты. С другой стороны, тормозяший функционал, кто то написал, и функционал прошел приемку. Не озаботившись, как оно будет работать у сотен миллионов пользователей, с ввполне хорошим и современным железом. Это вариант идеальный.
Насчет реалистичного, затруднюсь ответить, я разработчик. Обычно на текущей работе создают задачи по оптимизации функционала, и это приносит прибыль. Я уже понял ваш хитрый вопрос. Своим ответом я на него и ответил. Причина доход\расход.
Вы не один. У самого припекает.