Прелюдия
Это был обычный вечер четверга. Я вернулся с работы, сел за ноутбук, включил его, запустил Skype и начал привычно ждать, когда же он наконец загрузится полностью и целиком. И тут неожиданно я задумался — а почему он так долго загружается, да еще и система явно тяжело переносит этот процесс?
Я решил заглянуть в Task Manager, чтобы оценить, сколько ресурсов потребляет Skype в фоновом режиме. Но для начала небольшие предварительные расчеты. А сколько вообще это должно потреблять ресурсов? Я сейчас говорю про фоновый режим. Т.е. когда никакой видеосвязи нет, я ни с кем не говорю даже по микрофону. Все, что есть, это список контактов, который отображается в виде иконок и имен, и меню, в котором можно что-то выбрать.
Т.е. это одна форма, по сути, из которой можно запустить дополнительные меню. На этой форме один список. И текстовое поле для ввода сообщений кому-то, несколько кнопок. Лет 15 назад, когда я писал на Delphi, такое приложение (с одной формой) весило бы пару сотен килобайт. Конечно, с тех пор среды разработки стали потреблять гораздо больше ресурсов, компоненты визуальные стали богаче. Однако даже с учетом этого прогресса Skype в фоновом режиме должен весить где-то мегабайт 10 максимум. Ведь я же ни с кем не говорю и не звоню, на что там еще можно столько потратить?
Можно взглянуть на это дело и с другой стороны, как говорят математики, на эквивалентность. Без видеосвязи и разговоров по микрофону Skype предоставляет возможность просмотреть, кто из собеседников на данный момент в сети, а также отправить ему текстовое сообщение, ну и получить в ответ от кого-то текстовое сообщение. Т.е. это по сути ICQ — так что, ну наверное, в фоновом режиме, скорее всего, Skype должен и занимать в памяти примерно столько как ICQ? А теперь проверим на практике эти расчеты. Смотрим в TaskManager на потребление памяти:
Skype занимает в памяти 158 Мбайт? Вы это серьезно, учитывая, что QIP занимает 35 Мбайт? Ладно, 35 Мбайт это тоже пожалуй многовато, и с этим следовало бы разобраться, но моя заметка не об этом. Мы сейчас о Skype. Почему он занимает столько ресурсов — почти в 5 раз больше, чем QIP? На одну форму со списком контактов это как-то многовато, Вы не находите?
Что интересно, эта проблема волнует не только меня, если вы вобьете в Google "Why does skype consume so much memory", то там вывалится просто портянка различных обсуждений на форумах, почему новые версии Skype так много весят. Особенно радуют ответы. Например, реальный ответ на форуме сообщества Skype (я привожу мой вольный перевод ответа):
А почему вы считаете, что это много? Современные компьютеры имеют 4-8 Гбайт оперативной памяти. 140 Мбайт это такая мелочь по современным меркам, что вы даже этого не заметите при запуске.
Ага, ну да. Конечно. Если так все разработчики ПО будут рассуждать, то этак "никаких волостей не напасешься". Вопрос-то не в том, что мне памяти для Skype жалко (да и жалко тоже). Вопрос в том, что такого нового по функциональности прибавилось в новых версиях Skype (по сравнению со старыми), что они требуют так много памяти?
Но это-то ладно.Куда больше меня интересовал другой вопрос — процессор со Skype в фоновом режиме тоже не особо расслаблялся и периодически показывал даже полную загрузку. Возникает вопрос «Почему и как от этого избавиться?». На самом деле вопрос должен звучать так — как вообще разработчики умудряются создать такие громоздкие приложения? И что с этим делать?
Немного истории
Конечно, любой посетитель данного сайта наверняка хоть раз слышал про закон Мура о повышении производительности систем. В статье Free lunch is over приводится такая любопытная картинка:
Как видно, где-то в 2004-м процессоры достигли потолка в плане тактовой частоты. И последние 10 лет эта частота особо не растет. Следует ли из этого, что закон Мура перестал выполняться? Вообще-то, нет, и в статье ясно и четко объясняется почему. Просто производительность наших компьютеров теперь растет за счет других факторов (кэш и многоядерность). Однако загвоздка в том, что обычным одно-поточным приложениям эти факторы ускориться не помогут. И вот здесь возникает проблема. Дело в том, что многие производители ПО в наши дни ведут себя так, как будто на дворе по прежнему 80-е или 90-е, и оптимизация ПО в плане уменьшения количества тактов не представляет особой проблемы — просто можно немножко подождать, и процессоры станут гораздо быстрее.
Это справедливо не только для Microsoft, однако я сосредоточусь на конкретных примерах для нее. Джоэл Спольски в своей статье упоминает, что Microsoft удалось одержать верх над Lotus в 80-х годах в битве между Excel и 123 за счет того, что менеджеры Lotus допустили одну критическую ошибку — они попытались провести оптимизацию приложения. Конкретно они попытались ужать приложение так, чтобы оно всегда гарантированно умещалось в 640 Кбайт оперативной памяти. Они убили на это полтора года, и за это время Редмонд захватил рынок с помощью Excel, поскольку к этому моменту в строй вступали компьютеры с гораздо большими объемами оперативной памяти. Это решение очень дорого обошлось Lotus.
Однако вот что интересно — в наши дни такая стратегия, пожалуй, могла бы обернуться выигрышем — поскольку ресурсы стандартных десктопных систем уже не растут такими потрясающими темпами как 20-30 лет назад. Проблема в том, что в результате жесткой конкурентной борьбы того периода в выигрыше оказались компании, развивавшие функциональность приложений, игнорируя при этом производительность и оптимизацию. Эти-то компании и сформировали эту идеологию разработки, плоды которой мы пожинаем до сих пор.
Инфляция
К чему же это привело? К весьма любопытному явлению. Я никогда не откажусь от апгрейда оборудования, но внезапно в последнее время начал избегать без необходимости апгрейда ПО, из-за возможной инфляции. Под этим термином я подразумеваю, что тот же самый функциональный набор, который я имел в старой версии, в новой я получаю за большую стоимость в плане ресурсов процессора и оперативной памяти.
В английском языке есть устойчивая идиома, которая на русском звучит как «пытаться починить то, что не было сломано». Ситуация с ПО в последние 10 лет напоминает очень сильно эту идиому. Skype является одним из ярких примеров этого. Судя по форумам, эта проблема с памятью в старых версиях Skype не существовала, например, в версиях 3.x. Что такого усовершенствовали в продукте с тех пор, что он стал стоить настолько дорого в плане оперативной памяти?
То же самое, кстати, касается различных чат-приложений. Лет 15 назад чат, который за раз занимает 30 Мбайт оперативной памяти, выглядел нонсенсом. Однако сейчас это уже норма, хотя что же такого предоставляют нам чаты нынешние, чего не предоставлялось в то время?
Не стоит забывать и Microsoft Office. По-моему, версия для XP удовлетворяла всех. Конечно, как и любой продукт, она имела свои недостатки. Но были ли они настолько критичны, что потребовалось выпускать версии 2007, 2010 и т.д.? Я делаю в них те же самые документы, однако теперь приходится ждать гораздо дольше, пока эти системы загрузятся.
В оправдание мы слышим, что новые версии содержат новые возможности. Это да, я не отрицаю, но разве не выглядит странным, что при этом старые возможности требуют больше ресурсов?
Модульность и оптимизация
А все-таки, почему больше ресурсов? Здесь все объясняется тем, что большинство приложений достаточно монолитны. Нет, в плане организации кода они наверняка разбиты на модули с правильным разделением ответственности. Однако я называю их монолитными в том плане, что при загрузке приложения обычно загружаются сразу все его модули, хотя зачастую этого не требуется.
Вернемся опять же к Skype. Сейчас он очевидно сделан так, что при простом входе в систему сразу загружается в оперативную память масса модулей, ответственных непосредственно за звук, видео и т.д. Это при том, что обычный вход требует лишь списка пользователей и возможности обмена текстом. Эту систему можно было сделать иначе, загружая лишь самое необходимое. И только когда пользователь хочет реально начать видео-обмен, подгружается все остальное.
Оптимизация тоже важна, из-за того, что разработчики чисто физически не могут разработать весь код «с нуля», а вынуждены использовать уже имеющиеся библиотеки, которые были написаны без особого нажима на оптимизацию.
Представим себе, что разработчик каждой библиотеки сделал свою библиотеку на 5% медленнее, чем она могла бы быть, если бы он затратил дополнительные усилия на оптимизацию. Пусть библиотека 1 в своей работе использует библиотеку 2, а та библиотеку 3, а та библиотеку 4. В этом случае цепочка из 15 библиотек в случае аккумуляции задержек получает результат 1.05^15 = 2.07, т.е. приложение в худшем случае будет работать в два раза медленнее, чем любой из компонентов.
Я прекрасно знаком с фразой о том, что преждевременная оптимизация — это корень всех зол. Однако речь идет о преждевременной оптимизации, а не оптимизации вообще. Этот лозунг был прекрасен во времена, когда процессоры становились все быстрее на глазах. После достижения потолка этот лозунг начинает оборачиваться боком, когда старая версия приложения, написанная лет 15 назад, внезапно начинает выглядеть более предпочтительной, чем версия, выпущенная на прошлой неделе. Кстати, нельзя не отметить тот факт, что зачастую производители ПО пытаются принудительно заставить пользователей обновить ПО, именно потому, что особых мотивов выгоды для потребителя в данном случае нет.
Альтернативные примеры
В принципе программную индустрию ждет то же, что автомобильную после нефтяного кризиса 70-х, когда стало ясно, что бензин становится критически дорогим ресурсом. С тех пор автомобильные компании смогли снизить потребление двигателей где-то на треть, если я не ошибаюсь.
В мире ПО тоже такие примеры есть. В свое время мне очень понравился Erlang, который построен на концепции множества независимых легковесных процессов, которые объединены лишь общими сообщениями (это позволяет максимально использовать многоядерность). Кроме того, в этой среде действует принцип, который был явно позаимствован из интерпретаторов LISP — что каждый модуль и функцию можно загрузить и перегрузить на ходу при необходимости (и то же самое касается любого процесса).
Для сравнения, на Glassfish, если вы изменили один из нескольких сотен или тысяч классов, вам надо переустановить весь модуль (war/ear/jar). Горячая замена функций или классов на ходу там есть, но реализована очень слабо по сравнению с Erlang.
Будущее индустрии за приложениями, которые смогут использовать полноценно многоядерность, и не будут загружать сразу все возможные модули для всех фич, что есть в данном продукте. Т.е. программа сможет загружаться в базовой комплектации и потреблять столько ресурсов, сколько потреблял ее предшественник 15 лет назад, и при необходимости на ходу догружать все, что потребуется пользователю.
Комментарии (228)
amarao
05.05.2015 18:21+25Ответ один: фреймворки и совместимость.
Программа на дельфи в 200кб не сможет держать пять версий SSL с десятком криптоалгоритмов, поддерживать универсальный интерфейс во всех средах исполнения, декодировать json/xml/yml что-там-ещё, разбираться в сортах эмотиконов и т.д.
Хотите юникода? Держите — всего-то файл шрифта в 20Мб размером. Хотите эмоджи? Ну, вы поняли. Хотите удобную библиотеку для работы с сетью? Получите + мегабайт к VSS и два мегабайта к RSS.
nik_vr
05.05.2015 18:52+1В статье речь идёт о фоновом режиме. В фоне совсем не обязательно подгружать кучу библиотек, которые нужны только в режиме реального чата/видеочата.
MaximChistov
05.05.2015 19:00+11чтобы каждый раз при переключении в онлайн ждать пока оно все снова загрузит? но зачем, если можно загрузить сразу и не париться?
forgotten
06.05.2015 01:45-3А в чем проблема? Поднять с диска 10-20 Мб — не проблема даже для HDD, не говоря уже о SSD. Если, конечно, он в этот момент не занят каким-нибудь фоновым сканированием. WAIT, OH SHI~
webkumo
06.05.2015 02:01+9А в памяти это всё развернуть — бесплатно? Инициализация ресурсов — самая дорогая операция, сейчас её скайп производит на старте. Если инициализировать, как предложено в топике, по запросу — мы отхватим пачку проблем:
— не линейность выделенной памяти (именно по этой причине java-ентерпрайз предпочитает -Xmx и -Xms выставлять в одинаковые значения, для справки — это максимальный и стартовый размер хипа, основного используемого типа памяти, именно по этой причине инициализацию ресурсов стараются вынести в начало приложение — банально уменьшается фрагментация) приложению системой
— необходимость тратить время, когда пользователь ожидает, что операция произойдёт моментально («тормоза UI» — видео звонок сейчас почти не требует дополнительного времени на инициализацию — тратится только время на запрос ресурсов системы и подключение каналов данных)
— непредсказуемость поведения (а если система не смогла выделить памяти? — загружаемый модуль упадёт и утащит приложение)
Ну и ещё куча нюансов.
Areso
06.05.2015 10:26Имеем ситуацию. Скайп при загрузке грузит всё (кодеки, аудио, видео библиотеки). Комп загружается (без SSD) мучительно долго, в т.ч. благодаря скайпу. При звонке (нажатии на кнопку) реакция незамедлительна, вызов пошел.
Имеем обратную (до упора) ситуацию. При звонке (нажатии на кнопку), сначала прогружаются библиотеки (для пользователя это лаг интерфейса или программы) и только потом пошел вызов.
Имеем обратную ситуацию, но с хинтом: во время нажатия кнопки «вызова» сразу идет вызов, и в то время, пока пользователь слушает 1ый гудок грузим все библиотеки для аудио и видео. Причем, видео, тоже можно делать не по умолчанию, а только по нажатию кнопки — тогда загрузку видео библиотеки можно будет вынести туда.amarao
06.05.2015 10:51+8На входящем вызове мы имеем пользователя, который счастлив пропустить звонок из-за «тормозов компьютера».
eaa
06.05.2015 11:28-2неправда ваша. Пока пользователь нажмет кнопку приема звонка — на это уйдет секунда-другая, за это время можно спокойно подгрузить нужные библиотеки, тем более что не всегда нужны все библиотеки — если не нужно видео, то не нужно их и подгружать.
amarao
06.05.2015 11:33+7… Если в этот момент HDD не занят чем-то другим. Если будет параллельное IO, то мы получим отличный сценарий трешинга, когда ничего не работает на несколько секунд. Человек нажимает кнопку «ответить», а компьютер не реагирует — он занят более важными вопросами загрузки библиотек, парсинга конфигов LDD и т.д.
Отвечая на вопрос: да, можно сделать меньше. Нет, это существенно ухудшит потребительские свойства.
В следующий раз, когда вы обнаружите, что компьютер «тормозит», задумайтесь, что в этом месте разработчики в space-time tradeoff выбрали space, а вы за это платите time.evocatus
06.05.2015 13:02+1А я люблю поиграть на компьютере не выключая браузер, IRC-клиент и пр. Частенько надо много раз Alt-Tab нажимать (посмотреть прохождение в ютубе в браузере, включить/выключить скайп/тимспик и т.д.). И когда при каждом нажатии Alt-Tab комп начинает свопить игру, а потом наоборот (потому что вместе это всё не помещается даже с 8 ГБ памяти), это действительно бесит и это действительно медленно, а не «ой какой кошмар, он сможет ответить в скайпе не за 300мс, а за 1 секунду !»
amarao
06.05.2015 13:07+2Тогда вам надо либо проапгрейдить компьютер (у меня домашняя машина работает на 16Гб без свопа и я ни разу не наблюдал проблем с нехваткой памяти, не смотря на кучу открытых приложений, стимовые игры в бэкграунде и нативный клиент mmo (не стим)), либо сократить аппетиты.
Сейчас вы хотите, чтобы skype сделал 30Мб использования памяти вместо 180 (а игрушка при этом не выжрала ещё 150Мб и не свопилась так же). Если вы за этот случай готовы платить (и вам это будет стоить меньше, чем добавить памяти в компьютер), то ок. Я же вижу несколько обратную картинку.
Кстати, вообще говоря, вы можете сделать так, чтобы какие-то программы не свопились — правильно выставленные лимиты по памяти и приоритеты позволяют не вытеснять некоторые приложения.
cgroups вам в помощь.evocatus
06.05.2015 13:34Всё-таки это была не просто игра, а GTA V.
Насчёт приложений… я голосую кошельком (или самим фактом использования если программа бесплатная). В случае тех же мессенджеров альтернатив масса. Линуксовых WM/DE тоже немало. Лично я нахожу свой компромисс между фичами и потреблением ресурсов (а иногда и компромисса никакого не нужно).
Та же GTA V будучи портом с консолей отличается отличной оптимизацией, которая меня искренне радует — качество картинки прекрасное и использование ресурсов для такого качества адекватное по нынешним меркам. Если бы я увидел в стиме отзывы о том, что она плохо оптимизирована, постоянно подвисает и что-то всё время делает с HDD, я бы её просто не купил и всё.JDima
06.05.2015 13:49-116гб памяти на компьютере где-то трехлетней давности. Альт-таб для GTA5 проходит приблизительно мгновенно, ничего не свопит.
Что до отзывов — для хомячка любое ПО с высокими требованиями (хотя бы просто тормозящее на встроенной интеловской графике) является неоптимизированным, это аксиома.
0xd34df00d
06.05.2015 22:19Знакомые знатоки говорят, что GTA V выглядит хуже какой-нибудь BF4, а ресурсов жрет больше. Не могу сравнить вживую — не фанат серии GTA и неохота ради одних сравнений ее покупать, но, судя по скриншотам, так и есть.
heathen
07.05.2015 09:38То, что это консольный порт, значит, что выглядит она хуже, чем нативная игра: последнее поколение консолей — это какой-то треш 4-5летней давности. Ресурсов требует тоже меньше, да — теоретически. Потому что практически тоже не сильно оптимизировали под другую архитектуру.
SpaceEngineer
06.05.2015 17:09+4Именно так ведёт себя скайп на андроиде. От нажатия кнопки приёма вызова до появления устойчивой картинки проходит секунд 30. Если потом попытаться выйти в спосок контактов, опять лаги на несколько десятков секунд. Причём тормозит даже шторка андроида (ну, тормоза гуя — это его известная проблема). У меня старый одноядерный HTC Incredible S с 512 Мб оперативы, и я уже подумываю откатить систему на старый андроид 2.x (цианоген не предлагать, пока не исправят дикий жор батареи на этом девайсе), не ставить вообще никаких прог, кроме старого плеера и читалки, и нокогда их не обновлять. Потому что аппарат стал практически неюзабельным по прямому назначению — звонить и писать смс. Каждый день обновляется куча приложений, но быстрее и легче они не становятся. Скайп жрёт столько ресурсов, что даже лаунчер иногда выгружается (приходится ждать полминуты, пока загрузится рабочий стол с иконками). Я пользуюсь только стоковым браузером, потому что все сторонние (FireFox, Dolphin и т.д.) стали неповоротливыми монстрами, которые даже 3 вкладки одновременно держать не могут. А стоковый браузер постепенно всё хуже и хуже отображает страницы, потому что веб-программисы думают так же, как обычные программисты: «ну нафиг поддерживать старьё, пусть юзеры обновляют свои браузеры». Я регулярно прибиваю всякие фоновые службы гугла и т.п., но они всё равно грузятся сами (даже скайп!), и в итоге чтобы ответить на звонок или прочитать смс, надо ждать и материться секунд 10, пока звонилка/смс-приложение загрузится.
Вот так нас заставляют менять телефон каждый год. А я не хочу. Incredible S в своё время был флагманом с отличным экраном и стоил кучу денег. Мне от смартфона много не надо — звонить/писать по телефону и разным чатам/говорилкам, иногда лазать по инету, слушать музыку/смотреть видео, читать книги, и юзать навигатор. Всё это он прекрасно умел 3 года назад, причём почти без тормозов. Так почему же сейчас мне надо покупать новый телефон? Потому что программисты забили на оптимизацию? Там, где, казалось бы, она должна стоять чуть ли не на первом месте — в мобильных девайсах! Остаётся откатиться на старые версии андроида и приложений и пытаться как-то работать в них. Не со всеми прокатит — например, старый скайп, скорее всего, просто откажется работать, т.к. протокол сменился.heathen
07.05.2015 09:50Чёрт, проголосовал за комментарий после первой пары строк, а потом дочитал.
Вы никогда не пробовали старыми ручными жерновами сделать те же объемы, что делает современная автоматизированная мельница? Почему вы не жалуетесь на то, что это невозможно?
Мобильные устройства постепенно начинают поддерживать те же возможности, что и настольные приложения. Производительность новых устройств так же постоянно растёт — что и обеспечивает эту возможность. Мобильные браузеры поддерживают всё больше современных стандартов. И это прекрасно, я лично это только приветствую. И я лично понимаю, что невозможно обеспечить поддержку нового на том же железе, не потеряв в производительности. Попробуйте запустить Windows XP на каком-нибудь Pentium II или даже Pentium III начальных. Насколько хорошо она будет работать?
Исходя из ваших запросов, вы вполне можете пользоваться старым телефоном со старой прошивкой. Только вот придётся исключить просмотр современного веба и новых форматов видео. И, вероятно, навигатор — потому что 3d-карты ваш телефон почти наверняка не потянет уже сейчас или через некоторое время.
У меня OnePlus One. Он был куплен как раз для того, чтобы по возможности максимально долго поддерживать прогресс и при этом не переплачивать. Единственное приложение, которое действительно тормозит — это Skype. И, кстати, родная прошивка на телефоне — Cyanogen. Пока что у меня был рекорд в 2 дня 16 часов непрерывной работы. Это на тему поедания батареи Цианогеном.
Fuzzyjammer
07.05.2015 09:56> Попробуйте запустить Windows XP на каком-нибудь Pentium II
Нормально она работала на п2-333. При 64 метрах оперативы. Подтормаживала временами на тяжелом софте, но все равно система работала быстрее, чем андроид на прошлогоднем флагмане. А уж после добавления 128 мб планки так вообще летать стала.heathen
07.05.2015 10:50+3Знаете, году эдак в 2008 у меня был старенький Althlon XP какой-то. С 512МБ оперативы. Так вот ему было очень плохо под управлением свежепоставленной Win XP SP3, пока я не добил ему ещё полгига памяти. Поэтому не нужно мне рассказывать про PII, пожалуйста. Поставить можно было. Она даже запускалась. Нормально работать? Вряд ли. Ностальгия — такая штука. Ну, и понятие «нормально работать» — оно тоже субъективное. Кому-то и тридцатисекундные задержки — это нормально.
DrPass
09.05.2015 00:46-1Ключевое слово тут SP3 :) Чистая ХР была значительно менее ресурсоёмкой. Хотя и про 64 метра — тоже преувеличение. Если ее обкромсать по службам, то на 64 Мб она как-то сносно работала. Но без дополнительных манипуляций для приемлемой работы хотя бы в связке «Офис + IE и не больше двух-трех окон» требовалось 128 Мб. А для комфортной работы нужно было хотя бы 256 Мб.
heathen
10.05.2015 15:44Да, согласен, поэтому я и написал, что SP3 работала плохо на компе с 512МБ, а не 64. Свежепоставленная WinXP без сервиспаков могла работать без единого запущенного приложения на 64ГБ. Дальше прочитайте ещё раз остаток моего сообщения, начиная со слов «не нужно мне рассказывать про PII» и найдите отличия от того, что написали вы :)
SpaceEngineer
07.05.2015 11:34+1XP на третьем пне/атлоне, наверное, у всех была. Тут сравнение не корректно — она начинала тормозить со временем сама по себе, а не из-за апдейта софта. Если снести и установить свежую, вместе с софтом, всё летало. Апдейтом как софта, так и винды, я в те времена не пользовался, ибо инет был дорогой, чуть ли не рубль за мегабайт.
3D карты типа Navitel тел тянет, прокручивает конечно с тормозами, но гораздо быстрее и отзывчивее, чем «хардварный» автомобильный навигатор за 3000р. А вот с вебом да, беда.
Цианоген плохо оптимизирован конкретно под этот девайс. Заряд утекал сам по себе даже когда телефон просто лежит в режиме ожидания (всё, кроме телефонного модуля, выключено). Свежезаряженный утром телефон к вечеру уже садился, если ничего на нём не делать. На стоковой прошивке в таком режиме он у меня живёт 3-4 дня (звоню редко).
amarao
06.05.2015 10:50+4Примерно 40 библиотек. Загрузка библиотеки линкером — это чтение файла конфигурации линкера. Итого: порядка 80 мест откуда читать. Примерно по 2 операции на метаданные (мы же не хотим тратить память на чтение метаданных?). Итого — 160 IO только на начало файлов. При latency в 10ms — это 1.6 секунды. Плюс чтение самого файла (80Мб/с, 0.25с). Итого — 1.8с адского треска жёсткого диска при получении сообщения в skype.
Явный путь к успеху на рынке.eaa
06.05.2015 11:29+2путь к успеху у скайпа походу такой, что он один занимает времени на загрузку больше, чем вся убунту без скайпа.
JDima
06.05.2015 11:31+3Вся эта математика работает в идеальных условиях, когда компьютер ничем другим не занят, не отдает торренты, не имеет антивиря, имеет все файлы скайпа выстроенными по линеечке на диске и т.д. В реальности 1.8с будут недостижимой для большинства цифрой. 5-10 секунд уже реалистичнее.
VenomBlood
06.05.2015 06:00+2Приложение должно открываться из фона мгновенно. Если я буду подгружать двадцать dll'ек по несколько Мб каждая, да еще и инициализировать что-то — то при нажатии на попап приложение откроется не сразу. Оперативка стоит копейки, время разработчиков стоит дорого. Поэтому я за использование фреймворков.
mva
06.05.2015 09:04-4Может быть, «разработчики» будут отвечать за свои слова делом? Раз их время стоит дорого, а оперативная память — копейки, то, может быть, они таки будут покупать оперативную память всем пользователям своего ПО?
VenomBlood
06.05.2015 09:08+2Если все будут считать байты — просто ПО будет обновляться реже и стоить дороже.
mva
06.05.2015 09:15+1не вижу в этом ничего плохого, на самом деле.
VenomBlood
06.05.2015 09:2116Гб памяти стоят $100. Сравнивая со стоимостью софта — даже что-то совсем утилитарное типа текстовых редакторов, бекаперов, blu ray плееров — стоят в районе $70. Я предпочитаю один раз купить память чем платить больше за софт. Некоторый софт в принципе никто не будет скрупулезно оптимизировать по памяти потому что лицензия стоит > $1000, и повышать ее стоимость ради уменьшения потребления памяти просто не выгодно ни производителю ни конечному пользователю.
mva
06.05.2015 09:34+11)
100$
www.ok2.de/16GB-SO-DIMM-Intelligent-Memory--1027.html?MODsid=b3rhtccofnso1ho7va9fpm4ou5
2)Сравнивая со стоимостью софта
Как CEO IT-фирмы, занимающейся в том числе разработкой софта (а так же как человек имеющий опыт CTO в подобных же проектах) ответственно заявляю: стоимость «лицензии» на «аренду» софта у того, кто их продаёт — нечто эфемерное, берущееся с потолка и могущее стоить (на один и тот же продукт одной и той же версии при одном и том же уровне функциональности) как 10 копеек, так и 500$. Просто устоявшаяся бизнес-модель на рынке ПО позволяет так делать (кстати, заметьте, что вы не покупаете ПО, а арендуете).
3) Возьмём, кстати, например, браузеры: те же Firefox и Chromium. Они бесплатны (в денежном эквиваленте) для конечного пользователя (на нём зарабатывают иначе). Тем не менее, описанное в посте справедливо для них обоих в не меньшей степени, чем для Skype. Ну и их «удорожание» из-за найма более грамотных программистов, за которыми не нужно ничего «отимизировать», а так же из-за лёгкой оптимизации 3party-библиотек (которой они всё равно занимаются) для пользователя всё равно останется незаметным (см. недавний ввод в Firefox'е «слива» информации с quick-access панели в Facebook).mva
06.05.2015 09:37и, заметьте, я даже не оспаривал, что «самые удобные», являющиеся «стандартом отрасли де-факто» перечисленные вами «утилитарные» инструменты в указанных категориях являются мало того, что бесплатными, так ещё и СПО. А касательно «blueray-плееров», так я даже вот так сходу не могу найти ни один даже платный, который бы не паразитировал на наработках, сделанных FFmpeg/libav в том или ином виде.
VenomBlood
06.05.2015 09:42+1что «самые удобные», являющиеся «стандартом отрасли де-факто» перечисленные вами «утилитарные» инструменты в указанных категориях являются мало того, что бесплатными, так ещё и СПО.
У каждого свое, в какой-то области это СПО, в какой-то нет, а в какой-то стоит вообще очень больших денег. Покажите мне ведущий СПО (да хоть бы бесплатный) инструмент для разработки под C# и тоже самое для обработки фотографий хотябы.mva
06.05.2015 09:53-3вообще-то, речь шла только о перечисленных вами в комментарии, на который я отвечал, группах.
А так же, вся прелесть вашей позиции уже в ЭТОМ комментарии заключается в том, что если я сейчас, например, назовал бы monodevelop и xcode, то вы с лёгкостью можете это не принять потому что «у вас статистика другая».
// Я бы мог ещё и vim/emacs, кстати, назвать, ибо очень много знакомых в Google/Samsung/Yandex пишет именно в них, но для статистического большинства их уже, наверное, не хватит. Хотя в качестве аргумента против вашего несогласия со статистикой, наверное, прокатило бы :)VenomBlood
06.05.2015 20:43+1Visual Studio для C# — объективно лучшая среда по функционалу. В ее классе конкурентов у нее нету, а если принять во внимание наличие плагинов для нее — то разрыв только увеличится.
mva
06.05.2015 20:48-11) [цитата первого предложения предыдущего комментария]
2)объективно
говорит человек в дискуссии по заведомо субъективным вопросам.
3)функционалу
Ох, нехватает математиков на вас… :) cast 0xd34df00d, чтоли… :)VenomBlood
06.05.2015 20:50+1Касательно C# и Visual Studio и касательно набора возможностей — это вполне объективно. Просто по факту того что ни одна другая среда не покрывает всего функционала VS.
0xd34df00d
06.05.2015 22:23-1Да, интересно, когда уже граммар-наци будут за «функционал» вместо «функциональность» делать ататат так же, как за спутанные «одевать» и «надевать», например.
webkumo
06.05.2015 23:13+2/ГраммарНаци мод он/
Вот вы сами бы не путали и не лезли с комментариями, если не знаете:
— функциональность — конкретная возможность приложения, например видео звонок для скайпа — функциональность,
— функционал — набор функциональностей, например чат, список контактов, голосовой звонок, видео звонок для скайпа — основной функционал.
/ГраммарНаци мод офф/0xd34df00d
06.05.2015 23:15-2Функционал — отображение из некоторого пространства в R (или иногда в C).
evocatus
06.05.2015 13:14-2Что вы про всякую ерунду спрашиваете? Для картинок GIMP. А C# не нужен. Гораздо важнее нормальные САПР в разных сферах, системы компьютерного моделирования физических процессов.
VenomBlood
06.05.2015 19:44+2Мне нравится когда люди, совершенно не разбирающиеся в теме делают подобные утверждения. Вы в GIMP пробовали цветокоррекцию делать, например? Или вы считаете что графический редактор это просто «обрезать фоточки» и добавлять надписи?
А C# не нужен
Конечно не нужен, уже пошел увольняться с работы и сидеть учить язык, который вы считаете нужным, коллегам посоветую сделать то же самое. Самому не смешно?mva
06.05.2015 20:50К слову. Я пробовал. И не только я. Лично знаю несколько профессиональных фотографов, которые делают так же. Брат жив. ЧМДНТ?
VenomBlood
06.05.2015 20:54А я знаю человека, который в Paint.NET редактирует фотки. По набору возможностей GIMP сильно отстает от Photoshop и делать многие вещи, в т.ч. цветокоррекцию в них — сущий ад.
несколько профессиональных фотографов
Профессиональный фотограф сейчас так же как и СЕО — каждый второй. Я приму аргументы если приведете фотографа, который на профильных ресурсах находится в топах, а то сейчас «фотографами» становятся по факту приобретения зеркалки.mva
06.05.2015 20:581) кроме GIMP ещё есть и Krita, которая тоже вполне самодостаточный инструмент для РЕДАКТИРОВАНИЯ изображений, а не «СКАЧАЙ ТЫСЯЧУ ПЛАГИНОВ ДЛЯ ФОТОШОПА И ОНИ НАРИСУЮТ ШЕДЕВР ЗА ТЕБЯ».
// для последнего, кстати, есть как раз гимп, который таки имеет плагин для поддержки плагинов фотошопа, и с которым работают 99% оных
2) ок, понятно. Оффлайн-фотографы, ездящие со своими выставками по миру не котируются. Ок. Тогда скромно затыкаюсь.VenomBlood
06.05.2015 21:06+1Имена в студию) Раньше вот фотографы вообще без софта работали, это не значит что софт не нужен. Кроме того в разных жанрах разная обработка. Да и пара примеров не меняет картины. Я могу найти отличных программистов пишущих код в блокноте, это не значит что IDE не нужны и блокнот — альтернатива. Я изначально сказал что в GIMP гораздо труднее цветокоррекция, сейчас скачал GIMP, и вижу что мои притензии по большей части все еще в силе habrahabr.ru/post/112516/#comment_3602299
VenomBlood
06.05.2015 21:13+1Да, прошлый комментарий 2011 года, прошло более 4 лет, а даже CMYK и 16/32 bit per channel все еще остались в обещаниях, LAB даже не нашел в обещаниях (хотя здесь — может плохо смотрел).
VenomBlood
06.05.2015 09:40+2Ну можно еще показать оверклокерскую память, она еще дороже будет. Стандартная DDR3 для десктопа стоит $100.
Как CEO IT-фирмы, занимающейся в том числе разработкой софта (а так же как человек имеющий опыт CTO в подобных же проектах) ответственно заявляю
Сейчас каждый второй CEO, это ни о чем не говорит. Если выбирать между «меньше фич»/«дороже софт»/«жрет больше памяти» — я выберу последнее, куплю память один раз и забуду об этом. В конце концов это даже двигает прогресс в производстве более емких и быстрых железок.
С бесплатным софтом тот же компромисс, было бы меньше фич например.mva
06.05.2015 09:54Ну можно еще показать оверклокерскую память
Это — даже рядом не в той же группе, что и оверклокерская.
Это — единственная возможность иметь в немалой части ноутбуков эти ваши самые 16гб оперативной памяти. И 32Gb — во всех остальных. Потому что количество ноутбуков с 4 слотами под оперативку стремится к нулю.
Опять же, довольно вредно забывать о тренде на ещё бОльшую «мобильность» (планшетизацию).
это ни о чем не говорит
Это говорит как минимум о том, что у меня есть какое-никакое, но право на авторитетное заявление о методах вычисления стоимости лицензий на ПО.
0xd34df00d
06.05.2015 22:30+1Ну и их «удорожание» из-за найма более грамотных программистов, за которыми не нужно ничего «отимизировать», а так же из-за лёгкой оптимизации 3party-библиотек (которой они всё равно занимаются) для пользователя всё равно останется незаметным (см. недавний ввод в Firefox'е «слива» информации с quick-access панели в Facebook).
Не останется. Баги в трекере будут закрываться медленнее (программистов-то меньше теперь). Новые полезные (и не очень) фичи будут пилиться медленнее. В рекламной выдаче в поиске гугла появится на один пункт больше.
Да и прикол-то в том, что программистов, за которыми оптимизировать не нужно, их надо гнать из профессии вон уринированными тряпками. Невозможно заранее знать, что нужно оптимизировать, а что — нет, поэтому оптимизировать такие программисты будут вообще все и всегда, что не очень позитивно сказывается на скорости разработки и читаемости кода (ну, то есть, опять же, на скорости и качестве разработки). И, субъективно, чем код оптимальнее, тем больше инвариантов он требует, тем проще их случайно нарушить.
Гораздо проще и разумнее сначала написать, посмотреть, что получится, нужна ли фича вообще, и где она тормозит, а уже потом оптимизировать. Только есть шанс, что придет менеджер, скажет, что оптимизация не нужна, лучше еще одну фигульку в WebGL поддержать какую, или чего там нынче модно. Останется тебе голосовать ногами или патчами против такого софта.mva
07.05.2015 08:011) останется. Скорость закрытия багов в трекере зависит не от количества, а от качества программистов. Смотри историю Михая Щукана (в firefox) в соседнем топике.
2) Ты явно не читал /0. Там явно говорится про моральное устаревание модели «не занимайс преждевременной оптимизацией, а лучше вообще».
А то так можно прийти к выводу, что и программистов распараллеливающих задачи приложения СРАЗУ при написании, а не когда от скуки поюзали профайлер на продакшн-софте и увидели в нём затык, и по его наводке поюзали std::async и тем самым получили загрузку в 80 секунд (sic!) вместо 500 — тоже надо гнать из профессии и нужно делать именно так :)
mva
06.05.2015 09:47-4ну и да, отвечая на добавленное:
Некоторый софт в принципе никто не будет скрупулезно оптимизировать по памяти потому что лицензия стоит > $1000, и повышать ее стоимость ради уменьшения потребления памяти просто не выгодно ни производителю ни конечному пользователю.
Тут немного перепутана причина и следствие.
По поводу ценообразования на стоимость лицензии я уже говорил чуть выше. А вот по поводу «оптимизации» — всё дело в том, что для для модели ведения бизнеса, которая, почему-то устоялась в «копирастическом» мире (ПО, поп-книги, поп-музыка, поп-фильмы, и, которая, что довольно забавно, так же характерна для «российской» модели ведения «оффлайн»-бизнеса), и которая заключается в «вложить как можно меньше, по возможности не закладываться на долговременную перспективу, поиметь как можно больше прибыли здесь и сейчас», очень характерно нанимать «обезьянок» (пре-junior'ов, которые программируют, в основном, копипастой с SO, при чём, не всегда из удачных ответов), которым можно платить 1/6 от оклада нормального программиста. По этому, за ними и возникает необходимость оптимизировать. Нанимай они «нормальных» программистов — да, чистой прибыли было бы немного меньше, но качество (за которое, предвижу комментарии, «никто не доплачивает») было бы лучше. А так — да. «Если берут и в таком виде и несут мне много денег, то зачем я буду делать лучше?»VenomBlood
06.05.2015 09:50+7«копирастическом» мире
нанимать «обезьянок»
Нанимай они «нормальных» программистов
Ок, мне ваша точка зрения понятна.mva
06.05.2015 10:03+2Ай-ай-ай. Как же плохо делать заключения о точке зрения собеседника по «ключевым словам», а не по сути ответов в целом.
Ну и касательно «обезьянок» — это вполне устоявшийся англоязычный термин «monkey-coding», которого никто не стесняется. Равно как и никто не стесняется признавать, что для end-user софта в самом деле, очень часто нанимаются junior'ы за копейки (в то время, как тот же Bloomberg для своих внутренних разработок нанимает сплошь математиков-кандидатов наук) :)
Ну а про «копирастический» мир — вообще не вижу, как это может характеризовать мою точку зрения. Это же практически общепризнанный факт, что копирайт очень часто одерживает победу даже над здравым смыслом (man патентные_тролли, например).VenomBlood
06.05.2015 20:48+1Суть ответа была «копирасты нанимают говнокодеров потому что они недальновидные и жадные до денег, а пользователя им наплевать». По моему я вполне релевантно выбрал ключевые фразы.
«копирастический» характеризует вашу точку зрения примерно так же как слово «черножопый» характеризует точку зрения человека на определенные расы/национальности.mva
06.05.2015 20:55+1чините детектор, к слову. «Копирастический» лишь характеризует моё отношение к патентному/мздательскому (ака «смежному») праву в его текущем виде (и сторонникам его консерватизма, равно как любителям на нём наживаться), но никак не может характеризовать мою точку зрения на написание ПО в целом.
mva
06.05.2015 21:01кстати, забавную опчатку я допустил. Как это модно нынче говорить «по фрейду»*. Жалко, что время для редактирования уже закончилось и уже не исправить :)
* = для граммарнаци: да, я знаю, что в оригинале это имело значение только в контексте опечаток в сексуальном плане :)
amarao
06.05.2015 10:48-1А вы хотите, чтобы при переходе из фонового режима в режим сообщения оно вычитывало с файловой системы файл шрифтов на 20Мб, библиотеку с кодеками для картинок и т.д.? Я думаю, вот на такую оптимизацию общественность бы точно возбудилась. «Приходит сообщение и компьютер на 20 секунд уходит в адский своппинг». Да?
Ezhyg
06.05.2015 11:32+1Вот как-то mIRC поддерживает юникод, то есть, как минимум те же 20 мегабайт шрифта, при этом 20 он занимает только в пике потребления, а PSI+ занимает 60 метров — «как им это удаётся?».
И, да насчёт загрузки скайпа, вы не правы, я только что проверил, открыв его из трея и он почти две секунды грузил какую-то… херню, а два других чатика, открываются мгновенно, при этом в mIRC открыто 8 комнат с 3 разных серверов.amarao
06.05.2015 11:35Потому что вам эти 20Мб не показывают в списке памяти, занятой приложением. Если вы суммируете использованную память каждым приложением, оно у вас не сойдётся с разницей «всего памяти» и «свободная память».
Ezhyg
06.05.2015 11:56-1Ой… а давайте вы мне не будете рассказывать, где и что мне показывается…
я умею включать отображение дополнительных столбцов в виндовом менеджере задач и умею запускать системный монитор, и умею использовать процесс эксплорер, например.
И если уж вас интересует виртуальная память, то Мирк кушает 170, а скуйп — 350.
могу ещё рассказать про количество потоков, тикающие циклы обеих программ и так далее — «но мне лень».
eaa
06.05.2015 11:3420 мегабайт?
а 800 не хотите?
строчка из top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2645 XXX 20 0 817200 168804 24824 S 3,0 2,2 528:31.76 skypeamarao
06.05.2015 11:37+1Это virt. Allocated, but not used. Запись в табличке о выделении памяти. Потенциальный объём памяти, который понадобится, если придётся записать всё и вся.
Большой virt по сравнению с rss — это нормально (и это ещё один tradeoff: constant usage vs spikes).eaa
06.05.2015 11:53virt — это еще и своп, а не только неиспользуемая. учитывая, сколько оно грузится, есть все шансы, что оно свопит 600 и 160 не свопит… т.е. винт еще и свопом занимается персонально для скайпа. Вообще замечательно.
amarao
06.05.2015 11:56+5Извините, вы ерунду говорите. virt — это общий объём виртуальной памяти, выделенной приложению через mmap или brk. Та часть, в которую что-то было записано, относится к RES. В контексте приложения какая память в свопе, какая нет, сказать можно только через файл pagemap.
eaa
06.05.2015 12:09+1расскажите это тем, кто писал top и маны к нему
36. VIRT — Virtual Memory Size (KiB)
The total amount of virtual memory used by the task. It includes all code, data
and shared libraries plus pages that have been swapped out and pages that have
been mapped but not used.amarao
06.05.2015 12:29+2Ну так, и?
«Общее количество виртуальной памяти, испольуземой процессом. Это включает в себя все сегменты кода, данных и общие данные библиотек, плюс страницы, которые были выгружены в файл подкачки, а так же страницы, которые были выделены, но не используются».
А я что сказал? «общий объём виртуальной памяти». Не?eaa
06.05.2015 12:39+1Если сравнивать вместе то, что Вы говорите про RES и VIRT — то
17. RES — Resident Memory Size (KiB)
The non-swapped physical memory a task has used.
Вы же говорите, что «часть, в которую что-то было записано, относится к RES»
В то время как записано может быть и в то, что VIRT
Я не берусь утверждать, что все что VIRT есть записанная память и что она вся в свопе, но имею место предположить, что немалая часть этой памяти таки записанная, а не просто неиспользуемая.
bodqhrohro
06.05.2015 20:10+2Для свопа в top есть отдельная колонка, но её надо включать руками. virt — это просто количество затребованной процессом памяти; в современных ОС работа с памятью для юзерспейсных программ полностью виртуализирована и реально память выделяется только тогда, когда к ней начинаются обращения, чем программы невозбранно и пользуются, забивая себе побольше памяти. И разумеется, невыделенные страницы памяти в своп пихать никто не будет. Так что по virt-rss можно лишь прикинуть, в каких пределах вообще объём ушедшей в своп памяти, но не более того.
evocatus
06.05.2015 13:27Своппинг — это не любая дисковая активность, а использование виртуальной памяти, выделенной на ПЗУ для хранения данных, которые в ОЗУ не помещаются. И лично я, самый обычный юзер-недопрограммист, постоянно сталкиваюсь именно со своппингом. Потому что программы, пытающиеся хранить в оперативке сразу всё, в 8ГБ не помещаются.
amarao
06.05.2015 15:13+1С потребительской точки зрения «хр-хр-хр» в момент нажатия alt-tab или ответа на звонок — типовой swap-трешинг, именно это я и имел в виду, когда говорил про «свопится».
0serg
06.05.2015 15:31Неиспользуемые части фреймворков в норме и не должны подгружаться с диска.
Операционка просто мапит адресное пространство на файл лежащий на диске и все. В физическую память код подгружается при первом реальном обращении к странице.
malan
05.05.2015 19:34Если потребность в ресурсах является объективным следствием требований к совместимости, то не упрётся ли график роста этих потребностей через какое-то время в потолок, как это произошло с тактовой частотой или потребляемой мощностью?
Я не сильно в теме, но мне кажется новые криптоалгоритмы и версии протоколов тоже появляются не так часто как раньше. Всё вроде устаканивается.
idiv
05.05.2015 19:56+5Насчет Юникода — а раньше как Скайп нормально работал? И смайлики были. В этом случае вряд ли служит оправданием такое потребление.
Remper
05.05.2015 20:35Скайп вообще не показатель — походу с момента покупки майкрософтом его просто стали делать другие люди. Такое ощущение что в майкрософте уровень программистов сильно ниже чем был в самом скайпе (что в целом не удивительно).
Последняя версия у меня вообще вылетает через каждые n*100 секунд. Каждый апдейт не в радость. Версия под iOS вообще НИКОГДА не была хорошей, всегда висла, тупила и/или вылетала.
Riod
05.05.2015 20:48+2Если откинуть дизайн(на вкус и цвет фломастеры разные) расскажите что конкретно испортилось при MS.
150+ метров памяти скайп жрал в 2011(а тогда ее в компьютерах стояло существенно меньше)
Стабильность тоже от версии к версии была достаточно сомнительной, на одной машине не вылетал, на соседней вылетал.
Fuzzyjammer
05.05.2015 21:50+5При чем здесь МС? Скайп люто тормозил на cutting-edge машинах за годы до его покупки майкрософтом.
amarao
06.05.2015 11:15А он нормально работал? Я вот помню народ только и плакался как плохо skype себя ведёт и как много он жрёт. И тогда плакались не «в теории», а в практическом смысле — компьютер начинал сильно тормозить.
bogolt
05.05.2015 20:05+5Добавьте еще сюда:
* Увеличение размеров экрана, и как следствие увеличение всех изображений которые нужно держать в памяти.
* Добавление в программы звуков, и других свистелок
* Переход на 64 бита ( указатели занимают больше памяти ) хотя возможно это совсем крохи
* Использование языков далеких от процессора — а это уже не просто слой абстракции но куча накладных расходов на простейшие действия программы.webkumo
06.05.2015 01:35Указатели… Ну вообще зависит от реализации… могут занимать до 10-20% объёма данных… Но нормальным явлением мне видится что-то вроде 1-4%.
Error1024
05.05.2015 18:30+11Эх… Согласен, уже лет 5 не ощущаться увеличение производительности, увеличиваются лишь тормоза.
Многие программы сейчас переделываю на «легкий» интерфейс с усеченным функционалом, однако кол-во тормозов от этого только увеличивается.
LexB
06.05.2015 09:53+2В моем случае установка SSD привела к вау эффекту, все просто залетало. Я на эмоциях даже в старый ноут поставил SSD и ни разу не пожалел.
t3ns0r
05.05.2015 19:13+1Полностью согласен. Немного не по теме, но меня очень раздражает виндовс 7, которая со временем разрастается до невообразимых размеров на жёстком диске. Одна папка c:\windows на рабочем компьютере весит 37гб. Увеличить раздел не могу из-за ssd на 60гб, очистка стандартными средствами не помогает. Беда, в общем.
divanikus
05.05.2015 19:16+3Она не обязательно весит именно столько. Скорее всего растет папка WinSxS, но она набита хардлинками, которые стандартной считалкой считаются как отдельные файлы и по многу раз.
t3ns0r
05.05.2015 19:19+1Но сути это не меняет — постоянно приходится что-нибудь удалять, чтобы банально программы нормально работали, а не падали с ошибкой ввода-вывода.
a553
05.05.2015 19:52+4Вы можете использовать что-нибудь вроде TreeSize Free. Оно покажет настоящий размер файлов. Теперь можно заниматься оптимизацией.
Также полезно научиться переносить данные с одного диска (SSD) на другой (HDD) с помощью junction point. Например, в консоли mklink /J, есть плагин для totalcmd.
1. Вручную почистить c:\Program Files\WindowsApps\ от старых версий приложений (актуально для Win 8+)
2. Перенести из C:\ProgramData\ часто меняющиеся вещи на HDD, например БД MSSQL, Package Cache (БД MSSQL можно оставить, но не применять сжатие)
3. Применить NTFS сжатие для Program Files, Program Files (x86), ProgramData
4. Перенести C:\Windows\Installer на HDD
5. Применить NTFS сжатие для C:\Windows\WinSXS, assembly, Microsoft.NET (сначала надо взять owner-а себе, потом вернуть например SYSTEM)
6. Почистить видео драйвера например с помощью rapr (создать точку восстановления перед этим)
7. Точечно сжать проблемные места в C:\Users\..., часто меняющиеся вещи типа кешей браузеров лучше не трогать
Я так себе уменьшил размер своего системного диска с 90 ГБ (!!!) до более приемлемых 45 ГБ.
z0rgoyok
05.05.2015 20:16+3приемлемых 45 гб...(facepalm)
a553
05.05.2015 20:28+7Я в таких случаях вспоминаю цитату с башорга:
У Микрософта в превью Visual Studio 2010 написано в требованиям:
Minimum 75 GB available HDD space
первое мнение — наверно запятую забыли между 7 и 5
потом читаю дальше и НАРОД ГОВОРИТ, ЧТО НЕ ЗАБЫЛИ!!!!!!!heathen
05.05.2015 22:00Я помню, как в своё время ставил на машину с винтом в 40 МБ Borland Pascal 7, который в полной установке хотел 37 МБ. Так что это не новость вовсе.
vanxant
06.05.2015 04:19Я запускал БП7 на «Поиске» с 512К ОЗУ и одним флопповодом на 720К. Без винта вообще.
Грузилось примерно 5 минут, как игрушки на спектруме. Но после загрузки вполне себе работало.amarao
06.05.2015 11:17+3Дальше мы должны плавно перейти к тому, что в Elite на спектруме трёхмерную графику, алгоритмы полёта космических объектов и 8 вселенных, набитых звёздами, упихали в 40кб.
А потом плавно перейти к тому, что Урал-1 (100 операций в секунду, примерно 1000 машинных слов память) умудрялся ракеты на орбиту выводить.
Удачи жить в мире, где байты стоят больше, чем время людей.Mario_Z
06.05.2015 13:5140 КБ это было шикарно! Вот на БК-0010 было 16 КБ оперативки на код и данные и 16 КБ на экранную область (графика 512*256*2 цвета или 256*256*4 цвета) и вот в эти 16 КБ умудрялись запихнуть достаточно объемные игры со спрайтами 16*16 пикселей. Круче наверное только на калькуляторе БЗ-34 сажать на Луну космический корабль.
heathen
07.05.2015 09:34И? Голый Турбо Паскаль без защищённого режима, без поддержки WinAPI, документации, примеров, сырцов и т.д. — да, влазил наверняка на дискетку. Только это ж не о том.
Alexey2005
05.05.2015 22:54Вот и интересно, в чём причина подобного поведения системы. Почему Vista в аналогичной конфигурации обладает той же самой функциональностью, позволяет работать тем же самым приложениям, включая браузеры, IDE и игры, но при этом весит меньше и не жрёт ресурсы не пойми на что?
Они что, в Win8 пол-системы на .NET+WPF переписали, включая драйвера? Даже не знаю, чем ещё можно объяснить такие странности. За счёт чего-то же вырос объём в разы?
Grox
05.05.2015 23:41Что и зачем есть в винде можно почитать. Статей на тему для чего каждая папка хватает от самих MS, это кроме личных расследований. Наличие многих из этих папок действительно оправдано, они не просто так возникли, а для удобств, которых вы не замечаете, потому что они есть. Их легче заметить, если перейти на предыдущие версии винды и сделать, что-то не так. Этот пример про папку Installer. Хотя я не думаю, что такая реализация лучшее, что можно было сделать.
Error1024
06.05.2015 00:51На WPF встроенных приложений почти нет, как в прочем и .net приложений.
(Не учитывая Metro приложения)
webkumo
06.05.2015 01:42Не скажу за win8, но по поводу обсуждаемых выше в треде Win7 vs Win Vista:
— на старте на одном и том же железе Win7 гораздо активнее и шустрее (в том числе время загрузки)
— ресурсов (оперативки) Win7 кушает не больше Win Vista
— никогда не вставала остро проблема «много места занимает win-папка»… точнее встала один раз на рабочей машине — решил проблему утащив на другой раздел разные тулы… но когда решал смотрел в том числе и сайт MS, где было написано, что WinSXS можно изрядно ужать, поюзав тулу, которая «зафиксирует текущие версии». На самом деле папка активно растёт в размерах из-за того, что содержит _все_ версии обновленных компонентов. Это касается всех 6.0 и выше ядер (Win Vista, Win7, Win8)
Areso
06.05.2015 10:50Weather.exe на машине с SSD (Intel 520) запускается около 3-4 секунд и занимает в памяти 71 мегабайт (на HD экране). При том, использовать ноутбук с DD3L 2 ГБ и стоковым ЖД было настоящим мучением.
На недорогих планшетах с mSATA памятью с одной стороны лучше, с другой 1 гигабайт распаянного ОЗУ… Максимум 2.
IRainman
06.05.2015 17:35-1Вредные советы во многом даёте ;)
2. что бы работа с этими БД была медленнее, не надо так делать.
3. что бы каждый раз при открытии любого файла его приходилось целиком грузить в память для распаковки ;) не надо так делать.
5. тоже самое, что и с 3.
7. тоже самое, что и с 3.
Потом смешно наблюдать за людьми которые жалуются, что у них всё тормозит и которые винят винду во всех проблемах, которые понаделали сами.
С 4 согласен, папку ещё и пожать надо средствами ФС, при том даже без переноса (на многих железках лишь один накопитель).
С любыми переносами данных прошу обратить внимание на права и тонкости с защитой ибо при простом перемещении файлов права доступа очень легко херятся.
IRainman
06.05.2015 17:28Посмотрите сколько весит папка %windir%\Installer
У меня, из-за большого количества софта, именно она и занимает много места, около 7 ГБ. Пожмите её (средствами файловой системы) и тем самым очень прилично освободите место. На производительности при этом это почти никак не скажется, только во время установки апдейтов или установке удаления софта, что происходит не так уж и часто.
dom1n1k
05.05.2015 19:14+6Скайп развивается только к худшему, обновлял его только тогда, когда принуждали сменой протокола.
raid
05.05.2015 19:23+3Ну уж нет, я предпочту подождать лишнюю минуту при старте Скайпа, чем буду ждать эту же минуту при нажатии на кнопку звонка.
fundorin
05.05.2015 19:54+2На моей системе скайп занимает 87 мегабайт.
Ближайший к нему мессенджер, Viber, — 23 мегабайта.
Телеграм — 2.6 мегабайта.
Больше мессенджеров не установлено.
Файловый менеджер (Unreal Commander) — 11.
Дропбокс — 40.
Самый прожорливый процесс, после браузера, ESET — 116.
В целом, меня потребление памяти фоновыми программами устраивает. От Скайпа хочется избавиться, это да.
KvanTTT
05.05.2015 21:10А у меня вот вообще 300 Мб занимает. Хотя может это из-за того, что комп давно не перезагружал. Но утечки — это все равно, конечно, плохо.
1kvi1
06.05.2015 03:39+4В моей системе три аккаунта скайпа — потребляют 450МБ…
Решил проблему установкой 16ГБ ОЗУ…
Gorthauer87
05.05.2015 19:55+5объемы памяти растут быстрее, чем производительность процессоров. Поэтому приоритетнее экономить такты, чем ячейки памяти.
JSmitty
05.05.2015 20:53+7Знаете, несколько напрягает, что вполне живой ноут 5-летней давности невозможно использовать даже для веб-серфинга, хром и лис тормозят страшно — не хватает набортного 1Гб оперативки (и да, он распаян, слотов расширения нет). Офис 2003 (функционально равный 2010-му) и WinXP там же чувствуют себя вполне комфортно.
Riod
05.05.2015 20:56+4С веб серфингом сложнее. Усложнился интернет, и браузеры пытаются за ним угнаться. Поставьте того же лиса 5 летней давности и он не будет тормозить. А вот как хорошо он отобразит современный веб, это отдельный вопрос.
JSmitty
05.05.2015 21:18+1Пользуюсь Opera 12.17, когда прижимает — гружу Firefox. Но дело-то именно в том, что QA что у Mozilla, что у Google — списали все старше 3-4х лет в утиль. Конечно, это проще, чем оптимизировать билды, использовать удобные, но жутко толстые тулзы и либы.
На память приходит только два широко распространенных продукта, которым пришлось делать оптимизацию размера и скорости — Acrobat (на 8 или 9 версию вроде похудел) и IE (в дистрибутив с какого-то момента перестали включать видимо кусок файла подкачки).
MaxFactor
05.05.2015 22:31С Браузерами согласен, недавно надо было по работе разработать программу со встроенным браузером, так я взял WebKit движок подключил и какое же было мое удивление когда 4 вкладки сайтов начали занимать 300 мегабайт. Да что твориться с программами то.
Вот еще недавно искал инфу на форуме разработчиков гугла, которые Chrom поддерживают, и там промелькнул ответ — такого вольного перевода: Вы используйте TTimer(таймер) для передачи данных из одного потока в другой, т.к таймер висит в главном потоке и к нему имеют доступ подпотоки- после таких советов мои глаза выпали.
ЗЫ: у меня 16 гигтар памяти из которых 4гигтара занимает браузер — и как жить.
brzsmg
06.05.2015 08:33+1Вам не хватает 16 ГБ?
У меня 2 ГБ, Chrome всегда запущен + NetBeans + GIMP (Честно скажу: Скайп загружаю только на время разговора).
И все это как то уживается.
Иногда, конечно же приложения выгружаются в «Файл подкачки», в основном долго неиспользуемые вкладки браузера (благо их сделали отдельными процессами).
Mario_Z
06.05.2015 11:12+1Вы может не замечали, но последние версии Firefox кушают память на удивление экономно. Пользуюсь Opera с 2002 года и не менял ее никогда на другие браузеры. Я сам удивился, когда пришлось открыть около 30 вкладок со статьями HB и GT в Firefox. Вполне соизмеримо с Opera 12.17 получилось потребление памяти. Правда не хватает некоторых удобных мелочей, которые в Opera 12.17 идут в базовом варианте, но как раз с ограниченным количеством памяти жить можно.
nerudo
05.05.2015 22:42+1Как отобразит это вопрос отдельный, но он ведь и дыряв абсолютно. А хочешь «безопасную» версию — в придачу все плюхи, от которых не отказаться. Хоть на Links переходи…
casuss
05.05.2015 23:40А ведь железо-то как-то нужно заставлять покупать… А то вздумали сидеть на одном и том-же компе несколько лет и не платить ничего…
brzsmg
06.05.2015 08:38-1Может быть производители железа даже «перечисляют» за такую мотивацию.
ftdgoodluck
06.05.2015 11:44+1Им даже перечислять ничего не надо. Просто так работает текущее мировое общество потребления.
artsnz
05.05.2015 23:48Скайп же вроде в основе своей использует p2p и в фоновом режиме, когда вы не разговариваете, через вас все равно проходит трафик других абонентов для поддержания сети. Это как торрент в фоне, вы ничего не качаете, а он раздает, обновляет раздачи и тд и тп…
Меня вот больше беспокоят современные браузеры под разными ОС, которые при 5-10 открытых сайтах весом по мегу, жрут памяти под 1,2гб (ОС Х) не говоря уже о нагрузке на проц, причем тот же самый браузер (рыжий лис) под линуксом ест памяти ровно в 10 раз меньше порядка 120мб, при тех же открытых вкладках, винда расположилась где-то по серединке от 300 до 600 метров.
А в остальном согласен с автором, софт который раньше работал на пнях 133 с 16-64 мб памяти, сегодня требует два ядра по 2 ггц и 2 гб памяти, и ладно бы какой-то убойный функционал появился, ан нет, грустно все это… если оптимизировать большинство софта, то обновлять компы не будем по 10 лет, тогда загорюют производители этого железа, замкнутый круг однако.KvanTTT
06.05.2015 01:31+6После покупки скайпа MS, весь трафик проходит через их серверы.
yetanothercoder
07.05.2015 11:53после покупки ms скайп видимо идет тем же упомянутым путем экселя: оптимизацию в топку — главное новые фичи, производительность как нибудь подтянется )
Riod
05.05.2015 23:58+2Я не очен понимаю, какие критерии используются в данном случае для оценки скорости. Я прекрасно помню как производительности PC не хватало для видео 640x480 и сколько времени занимала архивация. Как тормозил банальный ресайз картинок и рип CD-аудио диска в mp3 требовал достаточно ресурсов, чтобы не мог работать в фоне.
Весь софт который требует серьезную вычислительную мощность сейчас может работать чуть ли не на одном ядре из доступных 4-8, а то и вобще выполняться на каком-нибудь специальном блоке(видео декодеры, шифровалки). Это все было не так давно. Да и с учетом инфляции за цену того компьютера сейчас можно купить такие железки, что вы забудите о каких-то ограницениях производительности.
Тормозят интерфейсы, они пишутся с большим уровнем абстракции периодически используя чуть ли не веб стек, что тут можно ждать.Gorthauer87
06.05.2015 12:47+1Да уж, веб это главный двигатель тормозов современных интерфейсов. В целом же, инфляция происходит из за того, что нет возможности сбросить груз прожитых лет. По просту говоря старые подходы стареют, обрастают жиром и дряхлеют.
То есть инфляция это плата за обратную совместимость.Alexey2005
06.05.2015 14:37+2Скорее, это плата за то, что вместо развития и совершенствования уже имеющейся архитектуры разработчики начинают наворачивать всё новые и новые слои абстракций.
Вот была система динамических библиотек. Она хорошо работала, полностью справлялась со своими задачами. Но нет, зачем-то решили перейти от библиотечного подхода к компонентному. Теперь у нас будут не библиотеки, а компоненты, которые представляют собой те же самые библиотеки, но только с обязательной необходимостью регистрироваться через реестр и кучу сложнейших механизмов. Всё это, естественно, тормозит и глючит.
Наконец, всю эту муть с GUID'ами, моникерами и DCOM'ом кое-как отладили, и кодерам этого показалось мало. Теперь наши компоненты будут храниться в текстовом виде. Ну чтобы помимо загрузки DLLки приходилось ещё поднимать парсер XML и парсить каждый раз всё это дело. Мотивировали якобы тем, что XML удобно читать человеку (интересно, кто этот человек, которому удобно в простом текстовом редакторе, без спец-IDE, читать такую корявую и негуманоидную вещь, как XML? А если всё равно юзаем спец-IDE и плагины, так не пофиг ли, XML там или уже бинарные данные?).
Естественно, вся эта XMLщина нещадно тормозила и глючила. Когда индустрия кое-как переварила очередную выдумку архитекторов, они придумали новую фишку: а давайте-ка вынесем компиляцию в рантайм. Раз уж XML всё равно парсится при старте приложения, так давайте и весь код будет компилироваться при старте! Сказано — сделано: подгружаем компилятор, линкер, и теперь у нас всё в рантайме, а значит — хорошо. Но вот беда, вдруг оказалось, что при первом старте теперь у нас даже приложения уровня Hello World грузятся по 15 секунд. Что ж, пусть они это делают лишь при первом старте, а потом скомпиленные заготовки сбросим куда-нибудь в WinSnS, чтоб потом быстрее было…
И вот спрашивается: а что мы собственно говоря получили полезного, навесив такую прорву абстракций?DjOnline
08.05.2015 15:42О, прям описание Magic Tune — простейшей утилиты Samsung для регулирования яркости монитора. Только она видимо нигде не сохраняет результат компиляции, и каждый раз с тормозами грузится заново.
x256
06.05.2015 01:00Ну они пошли по изначально кривому пути — стандартные браузерные контролы из системы… Ну приспичило делать UI в браузере, ну взяли бы CEF — по одному билду на каждую платформу. А так, весь этот зоопарк, как это вообще тестить…
158 мегабайт на скрине — сказка! У меня на 7-й винде IE-процесс часто падает или выдаёт (смешно) алерты типа «страница не отвечает». На маке с вебкитом — жрёт гиг памяти в обычном состоянии, до 2 гигов при активном использовании (поиск по чатам и т.д.)bodqhrohro
06.05.2015 22:56Гнёвый скайп до сих пор на Qt, а жрёт тоже нехило. Да и веб-гуйня через осликоконтрол (хоть даже старые добрые HTA) на винде была довольно разумным решением — пока ослик был легковесным небраузером… Но ранее в скайпе через ослик только форма логина была.
kosmos89
06.05.2015 03:28+1>В этом случае цепочка из 15 библиотек в случае аккумуляции задержек получает результат 1.05^15 = 2.07, т.е. приложение в худшем случае будет работать в два раза медленнее, чем любой из компонентов.
Ойойой! Ну и примерчик. Если у программы сложность O(N^15), то вам и десятикратное ускорение не поможет.
А поможет только смена алгоритмов на эквивалентные, но с меньшей сложностью.spirit1984 Автор
06.05.2015 11:27Нет, речь идет не о сложности программы в O(N^15). Речь идет, например, о стеке протоколов. Один протокол поверх другого, в результате небольшое замедление каждого протокола приводит к большому замедлению системы в целом.
kosmos89
06.05.2015 12:41+1Вы понимаете, что вы считаете неправильно? Если каждый протокол работает на 5% медленнее, то и весь стек будет на 5% медленнее. И никаких двух раз.
Например, следуя вашей логике, предположим, что программа скомпилирована другим компилятором, или написана на другом языке, который выдает код в 2 раза медленнее. В любой программе одни функции вызывают другие функции, что эквивалентно вызову библиотеки из библиотеки или одного уровня стека из другого. Допустим, глубина стека достигает 15 вызовов, что даже меньше, чем обычно. Согласно вашей методологии расчета, программа будет работать в 2^15 раз медленней. Т.е. в 32768 раз. Вам не кажется это нереалистичным?spirit1984 Автор
06.05.2015 13:03ОК, ситуации бывают разные. Возможно, протоколы вложены друг в друга, так что коэффициенты надо перемножать. Гораздо более распространено, когда они складываются друг с другом (считайте это суммарными задержками). Тогда 20 раз по пять процентов — это уже замедление вдвое.
Для того, чтобы задержка всего стека была пять процентов, нужно обеспечить годный конвейер в стеке, т.е. дополнительные ухищрения по оптимизации, да и не для каждой задачи так можно сделать.kosmos89
06.05.2015 15:34Хорошо. Давайте возьмем процессор на 5% медленней. Вместо Core i7 4790 будет у нас Core i7 4770. Протоколы вложены, как вы и предлагаете. И что, у нас программа будет в два раза дольше выполняться?
Если вы хотите дальше спорить, пожалуйста, приведите математические расчеты.
stepik777
16.05.2015 22:09ОК, ситуации бывают разные. Возможно, протоколы вложены друг в друга, так что коэффициенты надо перемножать. Гораздо более распространено, когда они складываются друг с другом (считайте это суммарными задержками). Тогда 20 раз по пять процентов — это уже замедление вдвое.
Вне зависимости от того, вложенные они или нет, нужно брать взвешенное среднее арифметическое, а не перемножать или складывать.
batja84
06.05.2015 04:40+3Тут вопрос что с хромом делать.? Некоторые из 10-20-ти его процессов (открыто много вкладок) умудряются по 1 гигабайту оперативы жрать? Это, собственно, как? Это сайт столько весит?
Zagrebelion
06.05.2015 08:02-2с хромом проще, вкладку (или несколько) закрыл — процесс убился, память освободилась. Firefox в этом отношении гораздо печальнее.
IRainman
06.05.2015 15:58+2Firefox памяти жрёт раза в 2.5 — 3 меньше Хромого. При этом в FF есть и работает ленивая загрузка вкладок (не грузит вкладки пока пользователь на них не перейдёт), а так же есть нормальные API позволяющие с помощью плагина полностью выгружать неактивные вкладки из памяти. Хромой же ресурс жрёт прост адово, и память и CPU, а при его запуске система часто встаёт колом на несколько секунд. Ещё Firefox очень удобен в плане API в широком смысле, к примеру, к нему легко прикручиваются древовидные боковые вкладки, которые очень удобно использовать на широкоформатном мониторе. К Хромому же вообще никаких улучшений интерфейса не прикрутить.
Помимо вышесказанного сама архитектура у Хромого откровенное говно, а уж о стабильности и говорить нечего в таких условиях, вот для примера ссылка:
www.buyincoins.com/s/windows--tablet_c356_s-arrival_DESC.html
откройте её в FF и Хроме ;) Почувствуйте разницу.
P.S. прошу прощения ссылку вставить как ссылку из-за идиотов не могу :)Fuzzyjammer
06.05.2015 16:46Пустой фаерфокс при старте занимает сразу больше ста метров, в процессе использования жрет память адово, не спешит ее освобождать после закрытия, если не прибить руками через таскменеджер.
От хрома, впрочем, я отказался еще раньше, т.к. мой ноут хоть и тянет легко пару виртуалок с windows server 08/12 с IIS и Exchange, хром ему не по зубам.
Я бы обвинил по привычке во всех бедах веб-дизайнеров, однако в случае с тем же ФФ я могу наблюдать, как после каждого обновления браузера тормозов становится больше, хотя просматриваемый контент мог давненько не обновляться.
Впрочем, дизайнеры все равно виноваты, а именно — в отказе от html-only версий сайтов.
Aingis
06.05.2015 17:04Плагины выключите. Часто виновниками оказываются они. В частности, популярный Adblock: blog.mozilla.org/nnethercote/2014/05/14/adblock-pluss-effect-on-firefoxs-memory-usage
Fuzzyjammer
07.05.2015 09:46Не использую плагины, даже флеш и джава в режиме «по запросу». Не в них дело.
Nikobraz
14.05.2015 10:40+2Я как-то решил проверить как с памятью Хром и Лис работают(сам на старой Опере сижу).
Открыл в браузерах Пикабу и мотал вниз до упора синхронно.
Лис при запуске сразу сжирает 300Мб, плавно доходит до 500 и потом потребление памяти прекращается, видимо на диск скидывает.
Хром и новая Опера жрут линейно, вплоть 3Гб.
IRainman
06.05.2015 16:06+1Доп: ну и ссылки на сами расширения:
древовидные вкладки:
addons.mozilla.org/rU/firefox/addon/tree-style-tab
автовыгружалка давно неиспользуемых вкладок:
addons.mozilla.org/ru/firefox/addon/unloadtab
Ни то ни другое в Хром не возможно в принципе.
conformist
06.05.2015 09:19Потребление памяти skype'ом еще сильно зависит от количества истории сообщений (в одном файле main.db) + различные конференции.
eps
06.05.2015 09:44+4Вот, например, инфляция ОС компьютеров:
malan
06.05.2015 14:44Калькулятор так вообще мгновенно включается :)
eps
06.05.2015 15:06Конечно.
Но это не калькулятор, это полнофункциональный компьютер с графической многозадачной ОС. Даже с поддержкой сети.
Главное, что выполняемые задачи те же самые. На Youtube было видео, где запускают бок-о-бок такую же парочку компьютеров, открывают на них текстовые процессоры, пишут пару абзацев оформленного текста, сохраняют и закрывают. Результат тот же самый: современные компьютеры делают вещи медленнее старых.malan
06.05.2015 15:27+2А почему бы на новый PC не поставить KolibriOS? Тоже ведь «графическая многозадачная ОС».
Вот тоже интересное видео об эволюции ПО.
DrPass
15.05.2015 09:52Photoshop — не слишком удачный пример. У него даже такая ключевая фича, как слои, появилась этак к версии 4.0, если мне память не изменяет. Но вы попробуйте сравнить по функционалу, хотя бы, MS Office 2000 и MS Office 2013. Причем Office 2000 вполне неплохо себе работал на первопнях с 64 Мб ОЗУ.
malan
15.05.2015 10:10А можно сравнить не 2000 офис, а 95-й? или вообще Office 1.0?
eps писал, что:
Современные компьютеры делают вещи медленнее старых.
А я просто указал, что старые компьютеры просто не могут делать тысячу вещей, которые делают современные.DrPass
15.05.2015 14:38> А можно сравнить не 2000 офис, а 95-й? или вообще Office 1.0?
Вы хотите сказать, что много лет назад компьютеры и программы были простые и малофункциональные? Зачем? Это и так очевидно. Речь тут идет о другом — о том, что ранее для реализации той или иной функции в программном обеспечении требовалось меньше вычислительных ресурсов, чем сейчас. Грубо говоря, эффективность использования ресурсов компьютера ухудшается. Как пример, могу привести, скажем, конфигурационный файл какого-нибудь абстрактного приложения. Лет 20 назад это был ini-файл, для работы с ним использовался нехитрый API, работающий с текстовыми строками на уровне «сравнил, вырезал текст, вставил другой текст, сохранил». Соответствующая библиотека «весила» два десятка килобайт. Сейчас программист с большой вероятностью будет сохранять настройки в XML. Для чтения/записи XML у него будет какой-то парсер, который умеет работать с DOM и SAX, умеет проверять схему документа, поддерживает XSLT-трансформации и еще массу крутых функций… которые имеют кучу полезных применений, но, черт возьми, совершенно не пригодятся в такой утилитарной задаче, как сохранение дюжины параметров приложения в настроечный файл, и их чтении при следующем запуске. И весит этот парсер десяток мегабайт, и всё это добро будет мертвым грузом загружаться вместе с приложением.malan
15.05.2015 15:19Грубо говоря, эффективность использования ресурсов компьютера ухудшается.
А вы пробовали сравнивать висту и семёрку? :)
А как эффективно старые программы работали с NTFS дисками, многоядерными процессорами, новыми видео технологиями?DrPass
15.05.2015 16:15У вас странные вопросы. Я вам пишу про то, что сейчас разработчики неэффективно используют мощности компьютера, а вы пытаетесь возразить, что, дескать, вот сейчас аппаратных фенечек больше. Одно никак не заменяет другое, и наличие мощных аппаратных средств не оправдывает ухудшение культуры разработки. Особенно учитывая тот факт, что взрывного роста аппаратной мощности уже не будет, который ранее компенсировал эту самую «инфляцию».
Кстати, что старые программы, что новые — они не работают с NTFS-дисками, по крайней мере, если это не системные утилиты. Программа вообще не знает, какая там файловая система на диске, это не ее забота.
SpaceEngineer
18.05.2015 10:46Поэтому я люблю статическую линковку. Линкер берёт из либы только те функции, которые используются в проге.
klirichek
06.05.2015 10:02Подумал — ну, у автора же винда… А посмотрю-ка у себя в убунте…
Был весьма удивлён…
Единственное — загрузка процессора всё ж меньше. Всего 164 секунды процессорного времени (это при аптайме 5 суток, при этом за это время была пара сотен сообщений в чате и один получасовой разговор)
Mario_Z
06.05.2015 11:04+1Вот уж действительно "Скайп — это гигабайты свежей информации".
Плохо что реальной альтернативы нет.EvilFox
06.05.2015 18:00Ну можно использовать SkypeWeb в Miranda NG (кстати хороший пример когда на оптимизацию не забивают, NG даже жрёт заметно меньше чем IM), правда пока ещё сыровато, но это глоток свежего воздуха после похорон SkypeKit.
spirit1984 Автор
06.05.2015 11:10Должен заметить в защиту Скайпа, что на планшетах он занимает меньше. Специально проверил на планшете у друга — там он занимал стабильно 40 мегабайт. Т.е. ребята из Редмонда могут оптимизировать, когда хотят. В статье я писал не о том, что конкретно это приложение сделано плохо. Речь идет о другом — что старые подходы к написанию таких вещей начинают очень плохо работать из-за потолка в скорости процессоров. Это не только справедливо относительно Скайпа.
В принципе функциональность старого скайпа до 2011 меня устраивала. И я бы хотел поддержки этих версий, просто чтобы на них ставили заплатки безопасности, если там какие-то критичные дыры. Я лично не просил большей функциональности и охотно пользовался бы в данном случае старой версии, пусть там изображение и похуже. Однако в том-то и дело, что с официального сайта старые версии не скачаешь (я вов всяком случае не нашел). Вдобавок не факт, что они запустятся вообще на новых версиях ОС.Gorthauer87
06.05.2015 12:50На Андроидах он крайне нетороплив, пока он стартует, я через телеграм уже успею сообщение средних размеров отправить.
GAS_85
06.05.2015 13:41Да запуститься то запуститься, соединяться вряд ли будет, но тут главное что EULA изменилась и пользоваться старой версией = не соглашаться с тем что весь трафик теперь не p2p, а идет через MS серверы.
bodqhrohro
06.05.2015 23:24+1Недавно была кардинальная (и вроде единственная в истории скайпа, на моей памяти точно) смена протокола с забаном старых версий десктопных клиентов. Так что не прокатит. Скачать-то можно с oldversion.com, вот только это бесполезный мусор уже.
alcr
06.05.2015 11:28+1Будущее индустрии за приложениями, которые смогут использовать полноценно многоядерность
и смогут забить на 100% не одно ядро, а все 8 :)
SovGVD
06.05.2015 12:13+2Просто купите новый компьютер, с 16 ядрами, в 3-4 раза большим объемом оперативки и SSD RAID и уже аж 2 програмки можно будет запустить.
Sychuan
06.05.2015 13:00+1«Как видно, где-то в 2004-м процессоры достигли потолка в плане тактовой частоты. „А разве закон мура про частоту? я всегда думал он про число транзисторов. Поясните дизайнеру.
spirit1984 Автор
06.05.2015 13:06-1Формулировки этого закона разнятся. Речь идет скорее о том, что до 2004 рост числа транзисторов приводил и к росту тактовой частоты. Теперь уже нет. Это отчетливо видно на графике. Т.е. теперь просто так, загнав больше транзисторов на схему, нельзя заставить приложение работать быстрее.
JDima
06.05.2015 13:42+3Рост числа транзисторов сам по себе не приводил к росту тактовой частоты. Снижение техпроцесса, удлинение конвейера и т.д. — да.
Производительность одного ядра в пересчете на единицу частоты либо ватт до сих пор продолжает расти. Всякие расширения вроде AVX, просто оптимизация работы конвейера на всех этапах… Современный 4-ядерный i7 4770k существенно быстрее старенького 4-ядерного Q6600, если уравнять их тактовые частоты, и это благодаря в первую очередь увеличенному бюджету транзисторов, на которых можно побольше всего реализовать. Разница раза в полтора-два будет. www.legitreviews.com/upgrading-from-intel-core-2-quad-q6600-to-core-i7-4770k_22470serg
06.05.2015 15:54Производительность одного ядра в пересчете на единицу частоты либо ватт до сих пор продолжает расти.
Это самая нижняя кривая на картинке в начале статьи. Рост есть, но немногим отличается от роста тактовой частоты :)
Разница раза в полтора-два будет
В сабжевой статье это в основном за счет памяти а не CPU имхо :).JDima
06.05.2015 16:05>Это самая нижняя кривая на картинке в начале статьи. Рост есть, но немногим отличается от роста тактовой частоты
Ну так очевидно — график обрывается перед тем моментом, когда началось самое интересное. P-IV (особенно поколение Northwood) даже потеряли в производительности по сравнению с ядрами P-III. А дальше вышел Conroe, который в два раза быстрее на такт, чем крутейшее ядро P-IV под названием Presler, и он, судя по отсутствию резкого скачка на всех графиках, там отсутствует.0serg
07.05.2015 08:39Там шкала логарифмическая, резкого скачка не будет, но да, шкала оборвана в 2007м и последняя точка там похоже как раз Conroe
JDima
07.05.2015 10:34Нет там conroe, иначе был бы резкий выброс по всем показателям, включая ILP (ну наверняка перевалил бы за 10 попугаев), частоту (тут понизилась бы) и т.д. Вероятно, там смотрели только ядра поколений P-IV и Itanium. Core 2 уж точно удостоился бы соответствующей надписи, все-таки весьма революционная штука, символизирующая переход от раздутия мегагерцев к повышению эффективности работы имеющихся.
0serg
07.05.2015 13:52+1Давайте посмотрим на графики еще раз: ILP выше почти вдвое, частоты рухнувшие с 3 ГГц до 1.4, резко сократившееся тепловыделение, появилось в 2006 году. Угадайте что это :D?
0serg
07.05.2015 14:05+1Кстати интересная релевантная ссылка прослеживающая тренды более подробно и до 2011 года (исходная картинка до 2009)
queue.acm.org/detail.cfm?id=2181798
IRainman
06.05.2015 16:20Дополню: i7 4770k vs q9550
cpuboss.com/cpus/Intel-Core2-Quad-Q9550-vs-Intel-Core-i7-4770K
Интересует нас всех лишь одна строка:
Significantly better performance per watt
12.73 pt/W
vs
5.44 pt/W
More than 2.2x better performance per watt
lucius
06.05.2015 14:13+3То же самое с Линуксами. Чем какое-нибудь сраное КДЕ 2, которое в 2000-е годы летало на 32 метрах оперативки, отличается от сегодняшнего КДЕ 4.0? Для меня, пользователя? Разве на рабочем столе КДЕ 2 нельзя запустить все те же самые приложения тех же самых версий? Сегодняшней версии браузер, почту, аську, медиаплеер, мощный графический редактор, программы аудио и видеомонтажа? Да можно. А что тогда добавилось с 2000 года, что уже в 512мег памяти не лезет? Автомонтирование бля флэшки? Блютуз с Wifi? Да это сраные копейки! А может, традиционный десктопный планктон «микшер-поиск-заметки-калькулятор» вырос в сотни раз? За счет чего? Чего ради?
© Каганов За что я ненавижу Линукс
BupycNet
06.05.2015 15:08Не обязательно использовать KDE. Я например под линуксом либо вообще иксы не запускаю. либо если нужен браузер и т.д. тогда запускаю иксы с Awesome. Последний потребляет около 500 килобайт памяти.
spirit1984 Автор
06.05.2015 15:19Здесь опять же полезна аналогия с автомобильной отраслью. Представьте себе, что из всех видов автомобилей купить можно было бы только майбах, неважно, нужен ли вам он или что-то менее мощное.
Если продолжить аналогию, то скайп следовало бы предоставлять в нескольких комплектациях. Например, lightweight-комплектация для скайпа усекла бы по минимуму все плюшки. Аватарки пользователей отображать? Не надо этого делать, чисто имена. Качество изображения? Установить верхнюю планку на уровне 2006-2007 годов. Поддержка различных смайлов и т.д.? Отображайте как в старые времена, просто текстом. Возможность передачи файлов и демонстрации рабочего стола собеседнику, видеоконференции? Отключить и это.
Это можно сделать легко на той же кодовой базе, что имеется для полной версии (при условии, что она не написана в стиле spaghetti). Тогда многие бы (не обязательно дауншифтеры) пользовались бы этой облегченной версией.Andrii_Z
06.05.2015 16:48Вы будете оплачивать труд программистов/тестеров/рекламщиков такого Скайпа?
Не нравится — напиши свое, и продвигай. И не надо говорить, что это невозможно, тьма альтернативных мессенджеров (WhatsApp, Viber, Kik etc etc etc) доказывают, что это не так.
egigd
06.05.2015 17:04+3Поддержка различных смайлов и т.д.? Отображайте как в старые времена, просто текстом.
Я бы переключился на текстовое отображение, даже если бы это потребовало бы больше ресурсов.
Заколебали эти тупые картинки, верните текстовые смайлы!
0xd34df00d
06.05.2015 22:14Я вот пишу одно модульное приложение в свободное время, и поэтому мне очень интересно, как, на ваш взгляд, стоит сделать ленивую подгрузку модулей по требованию для таких абсолютно реальных случаев:
- Пользователь хочет почитать в документочиталке публикацию в PostScript-формате. PostScript-модуль сам рендерить ничего не умеет, только лишь конвертировать в PDF, следовательно, он умеет работать только при доступном модуле чтения PDF. Открывать книгу, если да, то как, без загрузки необходимой логики на Тьюринг-полном ЯП?
- Пользователь выбирает в окне IM отправку файла, IM-модуль запрашивает список доступных модулей, могущих передать файл — среди них, например, модуль доступа к сетевым хранилищам вроде всяких Dropbox и Google Drive (ну тут можно, в принципе, хранить манифест со списком реализуемых интерфейсов).
- Пользователь закрывает крышку своего ноутбука, и модуль управления электропитанием рассылает всем сообщение, что скоро машина уйдет в спячку. Как определить, что нужно загрузить модуль управления питанием?
- Пользователь хочет отправить в чатике LaTeX-формулу, окруженную символами $$. Как определить, что пора загрузить латех-модуль?
Придумаю еще — напишу.
Enwony
07.05.2015 01:43Помню WinAMP ветки 2.x, который был оптимизирован по памяти хорошо — даже при сворачивании окна освобождалась память. А сейчас — skype на ubuntu 14.04 x64 ест около 200Мб, и я так понимаю, это комфортно лишь на машинах с большим количеством памяти.
Я часто вижу, что сравнивают потребление памяти программой и цену ее уменьшения только на один компьютер, вроде «оптимизировать потребление памяти на 10% стоит $40000, а модуль памяти на 2Гб $50», но ведь копия того же скайпа запускается примерно на 100,000,000 машин, даже экономия 10% памяти — это примерно 1,562,500 Гб свободной памяти — при цене на память в 50$ за 4Гб — это 19,5 миллионов долларов. Разница даже не на порядок.
Понимаю, расчет грубоват, но все же разница очень приличная.
Хотя, думаю, одной из вторичных тенденций (кроме внедрение нового/оптимизация старого) для увеличения использования памяти является tradeoff memory/cpu.
yetanothercoder
07.05.2015 11:57Для сравнения, на Glassfish, если вы изменили один из нескольких сотен или тысяч классов, вам надо переустановить весь модуль (war/ear/jar). Горячая замена функций или классов на ходу там есть, но реализована очень слабо по сравнению с Erlang.
ждем java9, молимся чтобы это получилось не так криво как osgi )
zencd
07.05.2015 16:37Насчёт скайпа — там особенная ситуация: любой экземпляр программы пропускает через себя и чужой трафик тоже, то есть говорить о каком-то режиме простоя здесь не приходится (изначально было так, по крайней мере).
DjOnline
08.05.2015 15:51Skype для меня стал неудобным в последнее время по 3м причинам:
1. Повисает во время разговора с видеосвязью, вплоть до сброса звонка. Я не хочу думать, это проблема Logitech или новых версий Skype, но раньше такого не было. Также начал переодически срываться в relay режим на ровном месте.
2. Поиск по истории теперь может ничего не найти. Раньше поиск искал по всей истории контакта, теперь требуется разворачивать историю за каждые несколько месяцев вручную, иначе он будет игнорировать эти блоки. Лютая ненависть. Раньше и так Skype был особо не пригоден для бизнес-коммуникаций, то сейчас это вообще говно какое-то.
3. Громадный контакт-лист в новых версиях. На 1200px по вертикали без аватарок теперь помещается всего 15 (!) контактов (ранее около 25). На нетбуках — 6-7.Riod
08.05.2015 18:223. У меня более 25 контактов видно на 1080 у вас что-то не то с настройками видимо. pp.vk.me/c623831/v623831617/2e6e4/JBzmq2LGyAc.jpg
DjOnline
08.05.2015 23:29+1Так выглядели прошлые версии времён 5-6. В 7.3 влазиет только 15 контактов.
IRainman
08.05.2015 19:54P.S. если нужно могу куда нибудь официальный MSI файл бизнес версии выложить.
nik_vr
На все 146% согласен с автором статьи, но, справедливости ради, отмечу, что ещё не все разработчики «забили» на оптимизацию. Скажем, тот же Total Commander. при всё возрастающей функциональности, по-прежнему экономно расходует память (даже будучи обвешанным плагинами). Или, например, IrfanView — функциональность растёт, а расход системных ресурсов заметно не увеличивается.
eduard93
Был бы IrfanView ещё и под Linux, вообще бы ему цены не было.
beeruser
Зачем нужен IV, если есть www.xnview.com/en/xnviewmp?
eduard93
Нет автоматического выбора следующей папки при достижении конца текущей папки.
Нет возможности предустановить папки для копирования или перемещения.