JAVA → Размер Java объектов. Используем полученные знания
В предыдущей статье много комментаторов были не согласны в необходимости наличия знаний о размере объектов в java. Я категорически не согласен с этим мнением и поэтому подготовил несколько практических приемов, которые потенциально могут пригодится для оптимизации в Вашем приложении. Хочу сразу отметить, что не все из данных приемов могут применяться сразу во время разработки. Для придания большего драматизма, все расчеты и цифры будут приводится для 64-х разрядной HotSpot JVM.
Итак, давайте рассмотрим следующий код:
А теперь проведем денормализацию:
Казалось бы — избавились от композиции и все. Но нет. Объект класса Cursor2 потребляет приблизительно на 20% меньше памяти чем объект класса Cursor (по сути Cursor + Position). Такое вот не очевидное следствие декомпозиции. За счет ссылки и заголовка лишнего объекта. Возможно это кажется не важным и смешным, но только до тех пор, пока объектов у Вас мало, а когда счет идет на миллионы ситуация кардинально меняется. Это не призыв к созданию огромных классов по 100 полей. Ни в коем случаем. Это может пригодится исключительно в случае, когда Вы вплотную подошли к верхней границе Вашей оперативной памяти и в памяти у Вас много однотипных объектов.
Денормализация модели
Итак, давайте рассмотрим следующий код:
class Cursor {
String icon;
Position pos;
Cursor(String icon, int x, int y) {
this.icon = icon;
this.pos = new Position(x, y);
}
}
class Position {
int x;
int y;
Position(int x, int y) {
this.x = x;
this.y = y;
}
}
А теперь проведем денормализацию:
class Cursor2 {
String icon;
int x;
int y;
Cursor2(String icon, int x, int y) {
this.icon = icon;
this.x = x;
this.y = y;
}
}
Казалось бы — избавились от композиции и все. Но нет. Объект класса Cursor2 потребляет приблизительно на 20% меньше памяти чем объект класса Cursor (по сути Cursor + Position). Такое вот не очевидное следствие декомпозиции. За счет ссылки и заголовка лишнего объекта. Возможно это кажется не важным и смешным, но только до тех пор, пока объектов у Вас мало, а когда счет идет на миллионы ситуация кардинально меняется. Это не призыв к созданию огромных классов по 100 полей. Ни в коем случаем. Это может пригодится исключительно в случае, когда Вы вплотную подошли к верхней границе Вашей оперативной памяти и в памяти у Вас много однотипных объектов.
Mobile Development → Нечеткий поиск слова на платформе iOS
Доброго времени суток! Сегодня мы хотим поделиться своей Developer Story… а также опытом оптимизации стандартных алгоритмов нечеткого поиска под мобильные устройства.
Все началось с просмотра лекций Стэнфордского Университета по курсу “CS193P Developing Apps for iOS”. Но в качестве опытного проекта не хотелось выдать очередной калькулятор.
Предыстория
Все началось с просмотра лекций Стэнфордского Университета по курсу “CS193P Developing Apps for iOS”. Но в качестве опытного проекта не хотелось выдать очередной калькулятор.
Программирование → Почему C быстрее Java (с точки зрения Java-разработчика)
В листе рассылки Git развернулась дискуссия о том, как язык программирования высокого уровня снижает производительность приложения, в связи с обсуждением JGit. Дискуссия особенно интересна, потому что в ней принимали участие программисты, эксперты высочайшего уровня как в C, так и в Java. Один из них — Шон Пирс (Shawn O. Pearce), известный Java-программист из компании Google, активный коммитер в Eclipse, соавтор Git и автор Java-имплементации Git под названием JGit. В своём сообщении он назвал реальные ограничения, с которыми сталкивается высококвалифицированный разработчик, пытаясь написать эффективный Java-код, сравнимый по производительности с максимально оптимизированным кодом C. Хотя письмо датируется апрелем 2009 года, но некоторые аргументы Шона до сих пор не потеряли актуальность.
List: git
Subject: Re: Why Git is so fast (was: Re: Eric Sink's blog — notes on git,
From: «Shawn O. Pearce» <spearce () spearce! org>
Как было сказано ранее, мы сделали много маленьких оптимизаций в коде Git на C, чтобы добиться реально высокой производительности. 5% здесь, 10% там, и внезапно ты уже на 60% быстрее, чем был раньше. Нико [Питре], Линус [Торвальдс] и Джунио [Хамано] — все они потратили определённое время в последние три-четыре года для оптимизации отдельных фрагментов Git, исключительно для того, чтобы он работал максимально быстро.
Виртуализация → Технологии работы с памятью в vSphere 5.0
На хабрахабре уже неоднократно обсуждались технологии работы с памятью используемые в различных гипервизорах. Эти технологии зачастую принято объединять под общим названием — Memory Overcommitment.
Цели которые обычно стремятся достигнуть применяя memory overcommitment две:
Цели которые обычно стремятся достигнуть применяя memory overcommitment две:
- Повышение утилизации физической памяти хостов преимущественно активными гостевыми страницами памяти на столько на сколько это возможно;
- Повышение общего значение консолидации виртуальных машин.
PHP → Работа с памятью (и всё же она есть)
Существует распространенное мнение, что «рядовому» PHP разработчику практически не нужно заботиться об управлении памятью, однако «заботиться» и «знать» всё же немного разные понятия. Попытаюсь осветить некоторые аспекты управлению памятью при работе с переменными и массивами, а также интересные «подводные камни» внутренней оптимизации PHP. Как вы сможете убедиться, оптимизация это хорошо, но если не знать как именно она «оптимизирует», то можно столкнуться с «неочевидными граблями», которые могут вас заставить изрядно понервничать.MySQL → Использование бинарного поиска для оптимизации запроса на выборку данных из песочницы
Введение
Сейчас очень популярна тем оптимизации работы с различными СУБД. На многочисленных форумах ведутся дискуссии о «самой лучшей СУБД в мире», но часто все это перетекает в необоснованные выкрики о том, что «я познал смысл жизни и понял, что самое лучшее хранилище данных — Х».
Да, несомненно, сейчас мы можем наблюдать активное развитие NoSQL решений, которые позволяют делать многое. Но данная статья не о них. Так вышло, что я сменил работу и в нагрузку мне достался один очень интересный проект на связке php+MySQL. В нем есть много хороших решений, но он писался без расчёта на большую аудиторию. За несколько лет существования количество активных пользователей начало приближаться к числам с 7 нулями. Так как проект представляет из себя подобие социальной сети с игровыми элементами, то таблица с пользователями оказалась не самой «тяжёлой» из всех. В наследство мне достались таблицы с десятками миллионов вещей пользователей, личных сообщений, биллинговыми записями и т. п. Проект начали рефакторить, разбивать на несколько серверов и достигли значительных результатов. Сейчас все стабильно.
Но недавно мне на почту прислали новую задачу. Суть заключалась в сборе статистики. Проанализировав требования я понял, что для выполнения достаточно написать один единственный запрос, выполняющий 3 INNER JOIN'а на таблицы, размеры которых впечатляли. Каждая таблица в среднем содержала 40 миллионов записей. Получается, что временная таблица состояла бы из 4*4*4*10^21 = 64*10^21 записей. Это колоссальная цифра. И загружать СУБД таким запросом для сбора статистики — непозволительная роскошь.
Далее, собственно, я и хочу представить решение данной абстрактной задачи, которое пришло мне в голову, когда я вспоминал занятия по информатике на первом курсе университета.
Блог компании IBM → Использование платформы Maximo, отечественный опыт
В прошлый раз мы рассказывали о теоретической части управления физическими активами и, пообещав продолжить эту тему на конкретных примерах интеграции Maximo на российских предприятиях, приложили лишь один пример того, насколько эффективно начинает работать система, где все данные взаимосвязаны, а производственные цепочки больше не выглядят отдельными звеньями общей цепи, позволяя понять и причину, и следствие, но что куда важнее — адекватно среагировать на изменившиеся обстоятельства и факторы.
Но Америка — Америкой. Куда интереснее взглянуть на то, как российские крупные предприятия, фактически — национально значимые, внедряют системы управления активами, по каким причинам и что, в итоге, они получают хорошего.
Google Web Toolkit → Высокопроизводительный GWT. Часть 1
Данный пост является началом серии статей про оптимизацию и улучшение производительности GWT-приложений. Поскольку материала у меня накопилось достаточно много, решил разбить его на 2-3 части.
Приступим к описанию того, что нас ждёт в первой статье.
Веб-разработка → Пять способов ускорить запросы API Facebook на практике
Ни для кого не секрет, что самым узким местом веб-приложений чаще всего являются HTTP-запросы к внешним серверам. Так, время загрузки данных запроса API много больше чем время, необходимое для выполнения большинства самых сложных скриптов веб-приложения.
За время работы с API Facebook я накопил несколько рецептов оптимизации запросов: как увеличить скорость работы скриптов, уменьшить их количество и ресурсоёмкость.
Способы, изложенные в этой статье, работают только с API Facebook. Но я не исключаю, что они могут быть применимы и в других сервисах, предоставляющих API.
За время работы с API Facebook я накопил несколько рецептов оптимизации запросов: как увеличить скорость работы скриптов, уменьшить их количество и ресурсоёмкость.
Способы, изложенные в этой статье, работают только с API Facebook. Но я не исключаю, что они могут быть применимы и в других сервисах, предоставляющих API.
MODx CMS → Modx и «ограничение» в 5000 документов из песочницы
Вступление
Modx — замечательный фреймворк, но на ресурсах и в разделах, посвященных modx, можно читать посты о неком ограничении фрейморка в 5000 документов, да и заказчики бывает спрашивают будет ли сайт работать, если страниц будет больше 5 тысяч.
Вы уже наверное догадались, речь пойдёт о modx evolution (версии 1.0.5).
Когда есть задача сделать сайт больше визитки, возникает вопрос: насколько много страниц может обслуживать cmf/cms и насколько быстро?
Modx знаменит своей гибкостью, и практически для любой задачи можно придумать несколько вариантов решений, но самое узкое место — кэширование, конкретно нас интересует файл assets/cache/siteCache.idx.php который содержит абсолютно всё, что можно закэшировать (кроме самих страниц, для которых есть свой кэш-файл вида assets/cache/docid_<ID страницы>.pageCache.php).
Обойти небольшие неудобства, которые могут возникнуть (если делать портал и хранить всё как документы modx) в большого сайта при текущей концепции кэширования modx можно несколькими способами, о которых немного ниже.
Что не так с кэшированием
Всё с ним так, но есть один момент — когда кэш очищается, главный кэш-файл siteCache.idx.php должен пересобратся заново.