Совсем недавно со мной поделились историей одной оптимизации (привет stanislaw), которая показалась мне довольно забавной.

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

for (A a : arrayListA) { 
    // do something
    for (B b : arrayListB) {
        // do something
        for (C c : arrayListC) {
            // do something
        }
    }
}

Доступа к коду у меня нету, поэтому я передаю лишь суть повествования. Есть некий метод просчета ситуации на карте, в котором происходит много итераций по разного рода циклам. Причём, граф объектов уже создан и изменяется лишь его состояние. То есть новых объектов фактически не создается… Но тем не менее профайлер показывал приблизительно такую картину (картинка из предыдущего топика):



И при частых вызовах метода сборка занимала довольно большую часть времени работы метода.

Здравствуйте! В этой статье я вкратце расскажу вам о процессах, потоках, и об основах многопоточного программирования на языке Java.
Наиболее очевидная область применения многопоточности – это программирование интерфейсов. Многопоточность незаменима тогда, когда необходимо, чтобы графический интерфейс продолжал отзываться на действия пользователя во время выполнения некоторой обработки информации. Например, поток, отвечающий за интерфейс, может ждать завершения другого потока, загружающего файл из интернета, и в это время выводить некоторую анимацию или обновлять прогресс-бар. Кроме того он может остановить поток загружающий файл, если была нажата кнопка «отмена».

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

Давайте начнем. Сначала о процессах.

Предлагаем вашему вниманию очередную подборку с ссылками на новости, интересные материалы и полезные ресурсы.

Что это и для кого (вместо вступления)

В данной статье я бы хотел рассказать о небольших результатах своей научной деятельности в сфере Text Mining. Этими самыми «результатами» стал небольшой FrameWork, который, пока еще, и до либы то не очень дотягивает, но мы растем =). Данный проект — реализация на практике некоторых, разработанных мною, теоретических положений. Как следствие этого я представляю возможности, которыми он может потенциально обладать в конце внедрения всех идей. Названо сее творение: «Text Mining FrameWork»(TextMF). Давайте в кратце рассмотрим, что именно будет позволять TextMF в своей первой финальной версии и что работает уже сейчас.

Представляю вашему вниманию подбору фреймворков, темплейтов, jquery-плагинов и иконок для создания интерфейсов в стиле Windows 8.

Добрый день, Хабражитель!

Уже достаточно много было рассказано о Swing и графике, также немного было упомянуто о различных незаурядных возможностях, предоставляемых сторонними библиотеками.

Сегодня же я представлю на Ваш суд «последний рубеж» погружения во все те возможности, которые предлагает нам Swing – создание своего Look and Feel класса, а также всего того, что потребуется по ходу дела.

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

Но даже если Вы не собираетесь делать свой LaF – советую всё же ознакомиться с содержанием. Уверен Вы найдёте много нового и интересного. И даже, возможно, поймёте в чём был корень той или иной интерфейсной проблемы, которая, вероятно, мучала Вас долгие месяцы и годы.

Tip: Если Вы не ещё не знакомы с графикой и Swing в Java более-менее тесно — советую сперва перечитать несколько статей на тему (к примеру оффициальный туториал, статью по Swing от Skipy или же мои предыдущие вводные статьи).

Знаете сколько в памяти занимает строка? Каких только я не слышал ответов на этот вопрос, начиная от «не знаю» до «2 байта * количество символов в строке». А сколько тогда занимает пустая строка? А знаете сколько занимает объект класса Integer? А сколько будет занимать Ваш собственный объект класса с тремя Integer полями? Забавно, но ни один мой знакомый Java программист не смог ответить на эти вопросы… Да, большинству из нас это вообще не нужно и никто в реальных java проектах не будет об этом думать. Но это, ведь, как не знать объем двигателя машины на которой Вы ездите. Вы можете быть прекрасным водителем и даже не подозревать о том, что значат цифры 2.4 или 1.6 на вашей машине. Но я уверен, что найдется мало людей, которые не знакомы со значением этих цифр. Так почему же java программисты так мало знают об этой части своего инструмента?

Integer vs int

Все мы знаем, что в java — everything is an object. Кроме, пожалуй, примитивов и ссылок на сами объекты. Давайте рассмотрим две типичных ситуации:

//первый случай
int a = 300;
//второй случай
Integer b = 301;

В этих простых строках разница просто огромна, как для JVM так и для ООП. В первом случае, все что у нас есть — это 4-х байтная переменная, которая содержит значение из стека. Во втором случае у нас есть ссылочная переменная и сам объект, на который эта переменная ссылается. Следовательно, если в первом случае мы определено знаем, что занимаемый размер равен:

sizeOf(int)

то во втором:

sizeOf(reference) + sizeOf(Integer)

Забегая вперед скажу — во втором случае количество потребляемой памяти приблизительно в 5 раз больше и зависит от JVM. А теперь давайте разберемся, почему разница настолько огромна.

Из чего же состоит объект?

Прежде чем определять объем потребляемой памяти, следует разобраться, что же JVM хранит для каждого объекта:

• Заголовок объекта;
• Память для примитивных типов;
• Память для ссылочных типов;
• Смещение/выравнивание — по сути, это несколько неиспользуемых байт, что размещаются после данных самого объекта. Это сделано для того, чтобы адрес в памяти всегда был кратным машинному слову, для ускорения чтения из памяти + уменьшения количества бит для указателя на объект + предположительно для уменьшения фрагментации памяти. Стоит также отметить, что в java размер любого объекта кратен 8 байтам!

Timsort, в отличии от всяких там «пузырьков» и «вставок», штука относительно новая — изобретен был в 2002 году Тимом Петерсом (в честь него и назван). С тех пор он уже стал стандартным алгоритмом сортировки в Python, OpenJDK 7 и Android JDK 1.5. А чтобы понять почему — достаточно взглянуть на вот эту табличку из Википедии.



Среди, на первый взгляд, огромного выбора в таблице есть всего 7 адекватных алгоритмов (со сложностью O(n logn) в среднем и худшем случае), среди которых только 2 могут похвастаться стабильностью и сложностью O(n) в лучшем случае. Один из этих двух — это давно и хорошо всем известная «Сортировка с помощью двоичного дерева». А вот второй как-раз таки Timsort.

Алгоритм построен на той идее, что в реальном мире сортируемый массив данных часто содержат в себе упорядоченные (не важно, по возрастанию или по убыванию) подмассивы. Это и вправду часто так. На таких данных Timsort рвёт в клочья все остальные алгоритмы.