Отказ от кастинга

Меня всегда раздражала необходимость кастинга при извлечении обьекта из библиотечной коллекции. Обычно в коллекции хранят обьекты одного известного типа, но при извлечении приходится всякий раз этот кастинг делать. Модные нынче дженерики не в счет. Там внутри тот же кастинг делается. Придумано исключительно для удобства программирования, но не для повышения эффективности программы.
Кастинг - отнюдь не самая тяжелая операция, но все же операция (по моим примитивным тестам время извлечения обьектов из коллекции возрастает примерно на 5% ). Возникает ли желание взять, скажем, ArrayList и на его основе сделать к примеру StringArrayList, заточенный под хранение стрингов? Чтобы исключить кастинг. Или это паранойя и маразм?

0

Danissimo (29.11.2006) Разрешите поделиться мыслями об узких местах. Не помню, кто сказал, что преобразование типов может выполняться в узком месте, и в этом случае было бы не лишним написать свой контейнер. Хочу возразить: писать свою коллекцию только для того, чтобы избавиться от приведения типов -- это все равно, что узкое место переписать на ассемблере. Нужно? Мой ответ -- нет. Знаю все возражения. Но также знаю, что как не переписывай квадратичный алгоритм, так он квадратичным и останется. Коэффициент может сделать его более крутым или пологим. Не более. Так что, я считаю, что преобразование типов проблемой стать не может. Следовательно, потребности переписывать возникать не должно.

Коллекции в Java общего назначения. Улавливаешь?

Метафоры какие-то, намеки. Ничего не понимаю.

0

Хочу внести свои пять копеек. Во-первых, кастинг действительно отъедает порядка пяти процентов (результат воспроизводится простыми тестами). Во-вторых, сия операция (по результатам моего теста) длится 3 наносекунды.



Теперь вопрос: много ли это? И еще один вопрос: много ли это для Java?

Например, операция деления двух long'ов примерно в 3 раза длительнее.

Собственно непонятно о чем спор. Если место действительно узкое и есть на это дело жалобы от пользователей и оптимизировать больше ну никак нечего, то почему бы и не написать свою коллекцию. Если же просто не дает покоя мысль о потере пяти процентов, то пожалуй не стоит. Хотя при избытке свободного времени можно и в последнем случае попробовать.

0

wind (03.12.2006) ...длится 3 наносекунды.

Вот это +1. До наносекунд вычислил. Вот только как?

просто некоторые люди мыслят быстрее

0

paradise (04.12.2006) Вот это +1. До наносекунд вычислил. Вот только как?

Всё просто: java.lang.System.nanoTime()

J2SE 1.5+



А вообще-то не обязательно наличие специального метода. Запустить длиннющий цикл, полученное время поделить на число итераций. Разумеется, это будет "грязный" результат, но для сравнительных тестов - в самый раз.

Если уж озобачиваться производительностью при работе с List, Set, Map, Integer, Double и прочим, то ИМХО лучше стоит посмотреть в эту сторону - http://javolution.org/

Использование этой либы даст прирост производительности гараздо больший чем простой отказ от кастинга.

0

Я натыкался когда-то на этот сайт. Если вы пробовали javolution , то интересны ваши впечатлениями.

0

Честно скажу, не пробовал. А вот код посмотрел. И вот че думаю:



1. Я не понял, зачем они в FastMap'е массив с Entry сделали прямоугольным. Есть идеи?

2. Мне не понравилось большое кол-во transient, что может привести (но не обязательно приведет) к борьбе за блокировку на шине памяти.

3. Я видел, что они используют Runnable(). Вопрос, они че, за моей спиной потоками рулят? Если да, то почему в доке я ни слова не встретил про то, какие ньюансы могут вылезти из-за этого? Dead-lock ли free этот код?

4. В чем смысл класса ReentrantLock? Нет, я понял, чего он делает. Я не понял, зачем он написан.



Дальше пока не смотрел. Но бенчмарки у них интересные. Очень даже. Ответственно заявляю. Только вот вопрос, они учитывали кол-во CPU, съедаемое GC?



Что не понравилсь: почему нету (или я не нашел) хеш-таблицы для long? Для остальных примитивных типов они не нужны, а вот для целых -- очень. Но их нету... И вообще нету коллекций для примитивных типов. Не понравилось.



Судя по названию классов, они пытаются управлять памятью. Смело. Настораживает. Пока не смотрел.



Вывод: перед использованием я бы сто раз проверил каждую строчку кода. И уж точно не доверял бы их бенчмаркам =))

0

я бы сто раз проверил каждую строчку кода

Это и отпугивает. Сразу приходит на ум простая альтернатива - а не проще ли добавить еще один компьютер?

0

Проще. А работает? Я вот каждый раз вспоминаю позырьковую сортировку. Представьте, что 100 тыс элементов она сортирует за 1 мин. Миллион -- за 100 минут (1.67 часа). Долго, да? Давайте увеличим тактовую частоту процессора в два раза. Тогда 100 тыс отсортируется за полминуты, а миллион -- за 50 мин =)) И это при том, что процессор в удвоенной частотой -- миф (видели 6-8 ГГц процы?), а если и не миф -- то состояние.



Я поимаю, что речь шла о втором компьютере. Тока это роли не меняет. К пузырьку второй процессор не прикрутить -- не параллелится алгоритм. Дело в алгоритме. И именно поэтому ребята и написали javolution. И знаете что, они молодцы. Если все то, что они пишут -- правда, и это работает, они молодцы.

0

Конечно, молодцы. Но этот проэкт известен уже несколько лет. И если там все так действительно революционно, он бы получил широкое применение, вплоть до включение в состав jdk. Может, он уже и применяется. Поэтому я и интересуюсь. Например, в клиентском приложения, где железа не добавишь точно, я бы его применил.

0

Javolution вещь, безусловно, хорошая, но в реальном приложении чтобы получить большой выигрыш нужно чтобы все было на них организованно. Для WEB-приложений это не реально - нужно JBoss, Tomcat сначала на них перевезти.



Transient и управление памятью и Threads их и спасает. Дело в том, что их классы умеют делать пул объектов в рамках треда. За счет этого увеличивается производительность (меньше операций new ObjecT()) и меньше нагрузки на GC.



Также у них собственная реализация Number-классов которые работают быстрее на операциях parse и сверки.

0

Dederer (08.12.2006) Transient и управление памятью и Threads их и спасает. Дело в том, что их классы умеют делать пул объектов в рамках треда. За счет этого увеличивается производительность (меньше операций new ObjecT()) и меньше нагрузки на GC.

С уменьшением нагрузки на GC я согласен. Но а как же thread contention? Ведь для того, чтобы получить объект из пула, мне нужно выполнить блокировку. Или они придумали неблокирующие алгоритмы? Теоретически это возможно. Но я не знаю неблокирующих алгоритмов, которые бы тупо не ели CPU. Вобщем, болше пока вопросов, чем ответов =))

0

За счет этого увеличивается производительность (меньше операций new ObjecT()) и меньше нагрузки на GC.

Вот это и противоречит концепции java, суть которой "вы создавайте больше новых обьектов, а мы будем совершенствовать GC" .

0

Вот это и противоречит концепции java, суть которой "вы создавайте больше новых обьектов, а мы будем совершенствовать GC" .

Если внимательнее почитать их сайт, то становится понятным их "поведение". Это сделано в угоду RTSJ - Real-Time Specification for Java.



А по поводу блокировок. Эти ребятки не так уж и просты чтобы использовать synchronization:

Javolution's collection classes (map, list, table and set) are all RTSJ-Compliant and support concurrent access without synchronization!

When a thread enters a concurrent context, it may execute multiple concurrent logics by calling any of the ConcurrentContext.execute(logic, arg0, arg1, ...) static methods. The logic is then executed at the same priority as the current thread and in the same memory area by a ConcurrentThread or by the current thread itself if there is no concurrent thread immediately available (as the number of concurrent threads is limited, see Javolution Configuration for details).

0

С подходами неблокирующих алгоритмов я знаком. Но они (в общем виде) грешат тем, что просто едят CPU. Это с одной стороны. С другой, они говорят: "When a thread enters a concurrent context..." Так используют они блокировки или нет? Если да, то -- thread contention. Если нет, то поедание CPU.



Соображения?

0

Думаю самое простое в этом случае посмотреть исходники. Они не большие, да и лицензия позволяет - BSD однако.

0