ПрелюдияЭто был простой вечер четверга. Я возвратился с работы, сел за ноутбук, включил его, запустил Skype и начал привычно ожидать, в то время, когда же он наконец загрузится всецело и полностью. В этот самый момент нежданно я задумался — а из-за чего он так продолжительно загружается, к тому же и совокупность очевидно не легко переносит данный процесс?
Смотрите кроме этого: Оборонное агентство США разрабатывает самоадаптирующееся ПО

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

Я решил посмотреть в Task Manager, дабы оценить, сколько ресурсов потребляет Skype в фоновом режиме. Но для начала маленькие предварительные расчеты. А какое количество по большому счету это должно потреблять ресурсов? Я на данный момент говорю про фоновый режим. Т.е. в то время, когда никакой видеосвязи нет, я ни с кем не говорю кроме того по микрофону. Все, что имеется, это перечень контактов, что отображается в виде имён и иконок, и меню, в котором возможно что-то выбрать. Т.е. это одна форма, по сути, из которой возможно запустить дополнительные меню.

На данной форме один перечень. И текстовое поле для ввода сообщений кому-то, пара кнопок. Лет 15 назад, в то время, когда я писал на Delphi, такое приложение (с одной формой) весило бы несколько сотен килобайт.

Само собой разумеется, с того времени среды разработки стали потреблять значительно больше ресурсов, компоненты визуальные стали богаче. Но кроме того с учетом этого прогресса Skype в фоновом режиме обязан весить где-то мегабайт 10 максимум. Так как я же ни с кем не говорю и не звоню, на что в том месте еще возможно столько израсходовать? Возможно посмотреть на это дело и иначе, как говорят математики, на эквивалентность.

Без видеосвязи и бесед по микрофону Skype предоставляет возможность просмотреть, кто из собеседников сейчас в сети, и послать ему текстовое сообщение, ну и взять в ответ от кого-то текстовое сообщение. Т.е. это по сути ICQ — так что, ну возможно, в фоновом режиме, вероятнее, Skype обязан и занимать в памяти приблизительно столько как ICQ? А сейчас удостоверимся в надежности на практике эти расчеты.

Наблюдаем в TaskManager на потребление памяти: Skype занимает в памяти 158 Мбайт? Вы это без шуток, учитывая, что QIP занимает 35 Мбайт? Хорошо, 35 Мбайт это также пожалуй многовато, и с этим следовало бы разобраться, но моя заметка не об этом. Мы на данный момент о Skype. Из-за чего он занимает столько ресурсов — практически в 5 раза больше, чем QIP?

На одну форму со перечнем контактов это как-то многовато, Вы не находите? Что весьма интересно, эта неприятность тревожит не только меня, если вы вобьете в Гугл Why does skype consume so much memory, то в том месте вывалится легко портянка разных дискуссий на форумах, из-за чего новые версии Skype так много весят. Особенно радуют ответы.

К примеру, настоящий ответ на форуме сообщества Skype (я привожу мой свободный перевод ответа): А из-за чего вы вычисляете, что это большое количество? Современные компьютеры имеют 4-8 Гбайт оперативной памяти. 140 Мбайт это такая мелочь по современным меркам, что вы кроме того этого не увидите при запуске.

Ага, ну да. Само собой разумеется. В случае если так все разработчики ПО будут рассуждать, то этак никаких волостей не напасешься. Вопрос-то не в том, что мне памяти для Skype жалко (да и жалко также). Вопрос в том, что для того чтобы нового по функциональности прибавилось в новых предположениях Skype (по сравнению со ветхими), что они требуют так много памяти? Но это-то хорошо.Куда больше меня интересовал второй вопрос — процессор со Skype в фоновом режиме также не очень расслаблялся и иногда показывал кроме того полную загрузку.

Появляется вопрос «Из-за чего и как от этого избавиться?». В действительности вопрос обязан звучать так — как по большому счету разработчики умудряются создать такие громоздкие приложения? И что с этим делать?Мало историиКонечно, любой визитёр данного сайта точно хоть раз слышал про закон Мура о увеличении производительности совокупностей.

В статье Free lunch is over приводится такая любопытная картина:Как видно, где-то в 2004-м процессоры достигли потолка в плане тактовой частоты. И последние 10 лет эта частота очень не растет. направляться ли из этого, что закон Мура прекратил выполняться? Вообще-то, нет, и в статье светло и четко разъясняется из-за чего. Легко производительность отечественных компьютеров сейчас растет за счет вторых факторов (кэш и многоядерность).

Но загвоздка в том, что простым одно-поточным приложениям эти факторы ускориться не окажут помощь. И вот тут появляется неприятность. Дело в том, что многие производители ПО Сейчас ведут себя так, как словно бы на дворе как и раньше 80-е либо 90-е, и оптимизация ПО в плане уменьшения количества тактов не воображает особенной неприятности — легко возможно самую малость подождать, и процессоры станут значительно стремительнее.Это справедливо не только для Микрософт, но я сосредоточусь на конкретных примерах для нее.

Джоэл Спольски в собственной статье упоминает, что Микрософт удалось победить над Lotus в 80-х годах в битве между Excel и 123 благодаря тому, что менеджеры Lotus допустили одну критическую неточность — они постарались совершить оптимизацию приложения. Конкретно они постарались ужать приложение так, дабы оно неизменно гарантированно умещалось в 640 Кбайт оперативной памяти.

Они убили на это полтора года, и за это время Редмонд захватил рынок посредством Excel, потому, что сейчас в строй вступали компьютеры с намного большими количествами оперативной памяти. Это решение весьма дорого обошлось Lotus.Но вот что весьма интересно — Сейчас такая стратегия, пожалуй, имела возможность бы обернуться выигрышем — потому, что ресурсы стандартных десктопных совокупностей уже не растут такими потрясающими темпами как 20-30 лет назад.

Неприятность в том, что в следствии твёрдой конкурентной борьбы того периода в выигрыше были компании, развивавшие функциональность приложений, игнорируя наряду с этим производительность и оптимизацию. Эти-то компании и организовали эту идеологию разработки, плоды которой мы пожинаем до сих пор.ИнфляцияК чему же это привело? К очень интересному явлению.

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

Обстановка с ПО в последние 10 лет напоминает сильно эту идиому. Skype есть одним из хороших примеров этого. Если судить по форумам, эта неприятность с памятью в ветхих предположениях Skype не существовала, к примеру, в предположениях 3.x. Что для того чтобы усовершенствовали в продукте с того времени, что он начал стоить так дорого в плане оперативной памяти?То же самое, кстати, касается разных чат-приложений. Лет 15 назад чат, что за раз занимает 30 Мбайт оперативной памяти, смотрелся нонсенсом.

Но на данный момент это уже норма, не смотря на то, что что же для того чтобы предоставляют нам чаты нынешние, чего не предоставлялось в то время?Не следует забывать и Микрософт 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 лет назад, и при необходимости на ходу догружать все, что потребуется пользователю.

Случайная статья:

• Результаты конкурса «нам нужны ваши мозги» от kingston
• Как поменять пароль в одноклассниках?

linkmeup #49. GNS3

Похожие статьи:

• Старый друг хуже новых всех, или чем опасны б/у оперативная память и ssd

  Здравствуй, Geektimes! Кризис на дворе — экономия в быту. Не грех задуматься о покупке подержанного железа, либо хотя бы не апгрейдить существующее без…

• Caref — умные часы для обеспечения безопасности детей и спокойствия их родителей

  Мелкий ребенок — это и проблемы и радость. Радость чадо приносит фактически неизменно. Но и неприятностей, которые связаны с детишками, достаточно…

• Обзор и сравнительное тестирование пэвм «эльбрус 401?pc». дополнение — вопросы и ответы

  Пожалуй, главным результатом публикации этого обзора, — кроме фактически ознакомления общественности с первыми свободными впечатлениями от нового…