Первым делом конечно же я побежал в маны JAVA по типам данным (http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html). Но увидев первые же строчки понял, что этой информации мне будет не то что не достаточно, она вообще не охватывает даже часть того вопроса, который стоял передо мной. Без сомнений, она достаточна и можно было используя эти данные, вручную вычислить сколько занимает тот или иной объект. Однако, одно дело вычислить, другое дело - получить результат программным способом. Поэтому требовалось нечто большее.
Тут на помощь как всегда пришёл добрый Google и вывел меня на страницу (Memory Usage in Java), где некий Dr. Heinz M. Kabutz был озадачен тем же вопросом, что и я. Применив свой опыт, он реализовал этот вопрос практически и показал "сырцы" с коментариями, каким образом он всё это делал. Используя его код, я решил провести собственное расследование.
При первых же тестах я увидел, что данные, которые были указаны в его результатах разнятся по сравнению со моими. Сначала я пытался найти ошибку, которую возможно я допустил. Но понял, что дело не в ошибке, а в том, что его тестирование проводились на 32-битной системе, я же тестировал на 64-битной, что придало большего контраста тестам: мало того, что можно узнать какой из объектов сколько занимает места в памяти, можно так же посмотреть, на сколько эти данные разнятся между разными системами. БИНГО!
По мимо тех объектов, которые привел Heinz, я решил расширить их теми объектами, которые чаще всего применяются при написании программ. Так же для сравнения я решил создать отдельный класс, куда включил различные виды объектов, чтобы можно было так же сравнить, когда целесообразнее создать отдельный класс как объект, а когда можно обойтись динамическим созданием объекта даже самого примитивного вида.
Ещё в его примерах я заметил некую не согласованность сравнения данных. Если BooleanArray и PrimitiveByteArray он сранивает по 1000 байт, для самых "прожорливых" объектов FullArrayList и FullLinkedList он почему то применяет 10000 итераций. Сравнивая ведра воды с количеством лаптей особо верную картину вряд ли получишь. Поэтому я решил для своих тестов применить определенные правила:
- там где требуется явное указание байта - это будет (byte)12;
- для целых чисел будет использоваться число 123, если это int или Integer и 1234567891234 если это long или Long;
- для типов с "плавающей запятой" будет использоваться число 123.45;
- строкам будет применяться текст "Field";
- размерность массивов или итераций там где это требуется будет 10000;
- тестирование будет производиться как на 32-х так и на 64-битной системе.
Описывать те примеры, которые приведены на сайте указанном выше, я не буду. Все данные сравнения вы увидите в таблице, приведенной в конце второй части этой статьи. Опишу только те примеры, которые были добавлены мной.
Array of String
Самым первым тестом я решил проверить именно этот тип данных, так как он не так уж и редко встречается в примерах кода Android SDK. Я знал заблаговременно, что использование массива строк очень не желательно. Однако, убедиться на сколько это не желательно, просто необходимо. И даже был удивлен, почему Heinz в своих тестах его не использовал в качестве наглядного примера. Первый свой пример я набросал таким образом, как я бы его написал в коде какого нить приложения. В итоге получился следующий объект:
public class StringArrayFactory implements ObjectFactory {
public Object makeObject() {
return new String[]{
"12",
"12",
"a",
"2012-02-29 11:47:55",
"123.45",
"123.45",
"2012-02-29 11:47:55",
"123.45",
"123.45",
"123",
"123",
"1234567891234",
"1234567891234",
"Field"
};
}
}Результат показал:
Factories.StringArrayFactory produced [Ljava.lang.String; which took 72 bytes
Здесь и далее в описании я буду приводить только результаты на 64-битной системе.
Не обратив внимания на малое количество байт в результате, я набросал следующий объект на 10000 итерации,
public class StringArrayTCFactory implements ObjectFactory {
public Object makeObject() {
int rows = 10000;
String[] col = new String[]{
"12",
"12",
"a",
"2012-02-29 11:47:55",
"123.45",
"123.45",
"2012-02-29 11:47:55",
"123.45",
"123.45",
"123",
"123",
"1234567891234",
"1234567891234",
"Field"
};
String[][] str = new String[rows][col.length];
for (int i = 0; i < rows; i++) {
str[i] = col;
}
return str;
}
}который мне выдал уже очень сомнительный результат:
Factories.StringArrayTCFactory produced [[Ljava.lang.String; which took 39680 bytes
Что за ерунда такая? Массив строк оказался оптимальней чем Vector или ArrayList? Да в жизни не поверю! Ни для кого не секрет, что класс String в любом языке программирования - зло, если его применять где не попадя. А с приходом UTF-8 и UTF-16 - это стало мегазло, нещадно пожирающее память. А если ещё этот объект "обернут" в массив... А тут такой результат!!! Но ларчик как всегда просто открывался. Создавая объекты таким образом, текст (или точнее сказать текстовые метки) создаются в памяти в виде констант, а массив уже заполняется ссылками на эти созданные объекты. Поэтому оба результата были "фейком". Следовательно, нужно привести оба объекта к динамическому созданию строк. Приводим эти объекты к следующим видам:
public class StringArrayFactory implements ObjectFactory {
public Object makeObject() {
return new String[]{
new String("12"),
new String("12"),
new String("a"),
new String("2012-02-29 11:47:55"),
new String("123.45"),
new String("123.45"),
new String("2012-02-29 11:47:55"),
new String("123.45"),
new String("123.45"),
new String("123"),
new String("123"),
new String("1234567891234"),
new String("1234567891234"),
new String("Field")
};
}
}Factories.StringArrayFactory produced [Ljava.lang.String; which took 520 bytes
public class StringArrayTCFactory implements ObjectFactory {
public Object makeObject() {
int rows = 10000;
int cols = 14;
String[][] str = new String[rows][cols];
String[] r;
for (int i = 0; i < rows; i++) {
r = new String[cols];
for (int j = 0; j < cols; j++)
r[j] = new String("Field");
str[i] = r;
}
return str;
}
}Factories.StringArrayTCFactory produced [[Ljava.lang.String; which took 5239608 bytes
Увидев результат последнего объекта, я был полностью удовлетворён ответом. Но состояние было в пору хвататься за валерьянку. Тут уже без дополнительных объяснений любому станет понятно, почему не желательно использовать подобного рода определения переменных.
Почему я заполнил StringArrayFactory именно такими данными, будет понятно дальше. Сейчас я не буду на этом останавливаться.
java.util.HashMap
Даный объект является почти самым популярным при использовании Android SDK. При чем чаще всего, первый объект мапирования как правило идёт типа String. После предыдущего примера на класс String я уже стал смотреть с подозрением, так как ожидать от него можно достаточно мощный разнос. Однако, каждый фрукт одинаково полезен, употреблённый в нужное время в нужном количестве. Поэтому посмотрим "что это за фрукт" HashMap и рассмотрим так же 2 варианта: сколько занимает "простой" объект и сколько он будет занимать, содержа в себе 10000 "строк" объектов. Так же учитывается тот момент, что первый объект будет типа String.
public class HashMapSimpleFactory implements ObjectFactory {
public Object makeObject() {
HashMap hm = new HashMap(1);
hm.put(new String("Field"), new Object());
return hm;
}
} Результат:
Factories.HashMapSimpleFactory produced java.util.HashMap which took 152 bytes
Объект HashMapTC для 2-го варианта выглядит следующим образом:
public class HashMapTCFactory implements ObjectFactory {
public Object makeObject() {
HashMap hm = new HashMap(10000);
for (int i = 0; i < 10000; i++)
hm.put(new String("Field"), new Object());
return hm;
}
} Результат выполнения:
Factories.HashMapTCFactory produced java.util.HashMap which took 65272 bytes
По правде говоря, получив результат в 152 байт для объекта HashMapSimpleFactory, я подумал, что опять накосячил с созданием строк. Тем не менее, пример оказался верным. Результата HashMapTCFactory я ожидал в 2 раза большего и был поражен, что он занимает всег 64к. Что само по себе ответила на мой вопрос "Почему так часто в Android приложениях используется этот тип данных".
Продолжение тестирования читайте в следующей статье "Использование памяти в JAVA (Часть 2)".
Комментариев нет :
Отправить комментарий