Оверхед скорее по памяти чем по производительности. На лично опыте знаю что при кеширование Integer - проверка на существование занимает дольше чем выделение.

А вообще - нужно наконец усадить жабовоятелей написать нормальный риджин инференс.

за пук бить длинной металической линейкой по рукам и попе
потом проветрить

большой.

а ещё круче какой-нибудь метод типа method(Integer i); или просто использование Integer (и прочих иммутабельных объектов), где ни попади, в итоге из-за кучи боксинга/анбоксинга можно получить забавный оверхед.

и да, если это разовое явление, то нужно тыкнуть носом
а если over9000, то убивать на месте, т.к. все относительно

Дык можно не кешировать, а например возвращать point, с package visible методами для изменения, там полно путей для изврата, вопрос надо ли.

риджин инференс

Ять, вы либо перевод пишите, либо латиницей. А то прямо мандалай какойто.

Иммутабельные объекты зато не надо копийровать. Ато есть маразмы а-ля:

http://www.docjar.com/html/api/java/io/ByteArrayOutputStream.java.html#141 - каково, а? Т.е. пишем в приватный буфер мегабайт данных, а паранойидальные разработчики берут его и тупо копируют.

вот уж да, удивляют некоторые типы, которые пишут английскими словами, но кириллицей и по правилам русской грамматики.

Взять и помотреть?

Как отправная точка:

# dtrace -qn 'hotspot*:::object-alloc { printf("new %s\n", stringof(copyin(arg1, arg2))); }'

дык палка то о двух концах. Или приходится копировать кучу данных при mutable объектах или плодить кучу immutable объектов (при их изменении), тут же отдавая старые gc.

с приведённым кодом - согласен, что маразм чистой воды.

оно тормозить будет от вывода этой строки гораздо больше, а так в IDE встроены профилировщики, кои показывают кол-во объектов, но толку.

Дык, яж писал, можно выдавать клиенту иммутабельный интерфейс, и всего то. Таки образом ничего копировать ненужно, да и тотже Point запрашивать 10 раз не придется, но наверняка тут свои косяки есть.

> но тормозить будет от вывода этой строки гораздо больше, а так в IDE встроены профилировщики, кои показывают кол-во объектов, но толку.

Ну так это ж для затравки. Строку выводить на каждый чих никто не заставляет. Можно накапливать статистику и выводить периодически. Ну если данных профилировщика хватает - вот и славно.

ну косяки immutable появляются сразу же когда мы из изменяем. хотя бы ставящее в ступор тех кто не читает спеки String s=new String();for (i ...) { s+=«что-нибудь}

и подобное может вылезать много где, создали новый объект старый забыли и опять...

извиняюсь если К.О.-шничаю..

Что йто вы меня не читаете.

public interface Point{
  int getX();
  int getY()
}

class PointImpl implements Point{
  int x;
  int y;
  //далее тупо геттеры для реализации интерфейса
}

// код в другом пакете:

Point p = someObj.getPoint(); 
// тут возвращается иммутабельный интерфейс, 
// но объект то не иммутабельный, т.е. ни копировать ни создавать 
// ничего не надо
p.getX()

ок.

В случае приведённом в тупокоде у нас гарантируется изоляция скопированного себе кода от поданного. Если я правильно понимаю, то в данном случае изоляции нету есть изоляция только в одну сторону, т.е. если someObj или кто-то ещё может менять значение того, на что указывает p (т.е. p.getX() может вернуть уже что-то другое), то у нас будет всё плохо. Если данных требований перед системой нет, то да, это хорошее решение.

под тупокодом имеется ввиду ссылка на либу, где копируется большой массив.

Если я правильно понимаю, то в данном случае изоляции нету есть изоляция только в одну сторону, т.е. если someObj или кто-то ещё может менять значение того, на что указывает p (т.е. p.getX() может вернуть уже что-то другое), то у нас будет всё плохо. Если данных требований перед системой нет, то да, это хорошее решение.

Да, причем в некоторых случаях, например с координатами часто нужно знать _ктуальные_ координаты, т.е. в обычном подходе придется их итеративно перезапрашивать, кроме того при работе в AWTThread есть призрачная гарантия что они не поменяются.

>Дык можно не кешировать

Да я не об этом. Я про то, что new в джаве офигенно быстрый.

А то что я называл - region inference. Мне казалось wlor уже всем раструбил про него =)

Мне казалось wlor уже всем раструбил про него =)

Я его практически не читаю, он ударен своими теоретическим задроствами, а реальный мир суров и на кодо-онанизм времени не дает.

Я вот вчера глянул в исходники одной вроде простой программки для Андроид (на java), так там вся программа размазана по десяткам вложенных друг в друга каталогов. Так что, все жаба-кодеры делают, чтобы это выглядело запутанно и непонятно, или это только на Андроиде такая мода? //код там вообще мне показался ужасен, но это отдельный разговор.

Вам, таки, стоит прочитать про яву немного, хотябы для того чтобы на ней никогда больше не писать.

После того, как за полтора месяца был написан AWT, в мае 1995 года вышла Java 1.0 и началась эра быдлокодерства для Web. Абсолютно все разработчики были настолько увлечены идеями ООП, что даже спустя 15 лет приходится иметь дело с таким говном ради обратной совместимости.

Так а якиеж альтернативы?

Альтернативы

Пиши сам на основе SWT без Gtk.

Я про модель событий а не про гуйню.

Смотри сам. SWT проектировали, опираясь на опыт AWT и Swing. Кент Бек, один из разработчиков SWT, принимал активное участие в разработке архитектуры Eclipse.

Почитай «Шаблоны реализации корпоративных приложений» Кента Бека.

«Шаблоны реализации корпоративных приложений» Кента Бека.

Там про что?

>Смотри сам. SWT проектировали, опираясь на опыт AWT и Swing.

К сожалению SWT - это загиб в противополжном напрвлении. Без JFace вообще не юзабелен. Да и с ним тяжко.

>Вам, таки, стоит прочитать про яву немного, хотябы для того чтобы на ней никогда больше не писать.

Белк, ты мне так и не ответил на вопрос.

> он ударен своими теоретическим задроствами

Пока весь мир «просто использует» наработки, кто-то должен двигать технологии вперед ;)

Оверхед очень маленький. Выделение памяти в джаве очень быстрое, короткоживущие объекты собираются generational GC тоже очень быстро. Вряд ли это может стать причиной плохой производительности.

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

Там про всё буквально. В этой тоненькой книжечке вся суть, по сравнению с которой Стив Макконнелл — просто вода.

Это Ынтерпрайз, детка. Привыкай. Там нормально для калькулятора создавать овер 9к объектов и жрать ресурсы гигабайтами.

Как удалось засунуть Eclipse в калькулятор рассказывается в другой книжке Бека.

что меня всегда удивляло - т.к. это люди прочитавшие кучу книг, которые постоянно ссылаются на кого-то, употребляют «умные» слова, а на практике ничего не умеют и делают детские и глупые ошибки

> Выделение памяти в джаве очень быстрое, короткоживущие объекты собираются generational GC тоже очень быстро

Но все же медленнее, чем просто сдвигом SP (1 инструкция vs. до хера, где до хера = O(размер первого поколения)). Так что region analysis рулил бы, если бы его они осилили.

> Выделение памяти в джаве очень быстрое,

тут да, всё понятно.

короткоживущие объекты собираются generational GC тоже очень быстро.

а тут обоснование будет?

а тут обоснование будет?

Поверхностное описание можно тут почитать: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generation...

Вот в жизни не поверю, что плодящиеся и тут же становящиеся ненужными объекты не будут сильно тормозить программу. Даже учитывая все оптимизации сделанные в gc на сегодняшний момент, хотя может быть потомк, что описание слишком поверхностное, оно не выглядит хорошим обоснованием. Ну да ладно, может и правда.

Ну вот набросал небольшой синтетический тестик: http://pastebin.com/WHiRrBHk

если закомментить строчки с a и раскомментить строчки с b, то цикл не будет создавать объекты, иначе в каждой итерации создаётся объект класса Integer.

Скорость с созданием объекта у меня примерно 87032201 (т.е. 87 миллионов объектов в секунду). Скорость без создания объекта у меня примерно 204081632, т.е. примерно в 2.5 раза больше.

Мне немножко лень писать этот тест на С++, но я думаю, С++ здесь отстанет от Java, если в каждой итерации создавать объект в динамической памяти и удалять предыдущий.

Просто у таких людей нет постоянной практики и окончательно сформированной точки зрения на ту или иную проблему. И иногда изложения взглядов этих людей на ту или иную проблему понимают и принимают буквально как РУКОВОДСТВО_К_ДЕЙСТВИЮ, что глупо втройне. Нужно включать собственные мозги и вести ДИАЛОГ, приближаясь к подходящему в конкретном случае решению.

> Нужно включать собственные мозги и вести ДИАЛОГ, приближаясь к подходящему в конкретном случае решению.

ты в задаче на три класса и 20 строк сделал неправильно ВСЕ - неправильно спроектировал самый базовый класс Resizeable, сделал левое наследование, получил левый нерабочий метод в «квадрате», написал костыли, чтоб заткнуть кривизну, кидаешь абсолютно нелогичное исключение в этом костыле, еще и по непосредственной реализации тебе указали на ошибки - какой тут «ДИАЛОГ»? что в данном случае обсуждать, если ничего дельного от тебя не было, кроме «умных» слов и ссылок на разных авторитетов?

в яве классы в своих файлах, директории отражают их иерархию //К.О.

> Мне немножко лень писать этот тест на С++, но я думаю, С++ здесь отстанет от Java

в С++ можно прямо указать в new, где будет «создан» объект - так что если говорить про постоянное удаление/создание, то С++ тут выиграет без вопросов, если создавать сразу много объектов - то опять же в С++ очень просто подключить пул памяти, и опять же С++ впереди с большим отрывом

в С++ можно прямо указать в new, где будет «создан» объект - так что если говорить про постоянное удаление/создание, то С++ тут выиграет без вопросов, если создавать сразу много объектов - то опять же в С++ очень просто подключить пул памяти, и опять же С++ впереди с большим отрывом

Про большой отрыв не уверен :)

> Про большой отрыв не уверен :)

ну в твоем примере для С++ вообще не будет аллокации памяти, только дергаться конструктор/деструктор, если есть, а если нет, как опять же в примере, - так вообще ничего будет происходить с включенной оптимизацией, а это явно быстрее чем вариант на Java :)

если же сравнивать с пулом - то тут не будет никаких мелких действий и дефрагментаций, одной командой просто «забываем» мусор, после отработки операции и все, да и выделение памяти будет по сути просто инкрементом указателя

неправильно спроектировал самый базовый класс Resizeable

Resizeable — это интерфейс, а не класс. Очнись, мы о Java говорим, а не о C++.

сделал левое наследование, получил левый нерабочий метод в «квадрате»

Код рабочий. С защитой от левых данных. Можешь сам проверить.

чтоб заткнуть кривизну

Это да. Я решил показать, что может делать с наследованием, кто с ним столкнётся. В AWT такой кривизны навалом.

абсолютно нелогичное исключение в этом костыле

Абсолютно логичное — исключение словит клиент там, где попытается использовать квадрат в качестве разностороннего прямоугольника.

и по непосредственной реализации тебе указали на ошибки

Кто указал? Ты что ли?

По-моему, весь примерный код по теме писали только я и qnikst, который высказывал хоть какие-то сомнения. Вот с ним диалог вести можно, с тобой — не, тут непробиваемая защита по типу «сам дурак».

что в данном случае обсуждать, если ничего дельного от тебя не было, кроме «умных» слов и ссылок на разных авторитетов?

Ты не привёл ни строчки правильного с твоей точки зрения кода, что вообще можно с тобой обсуждать?