Портирование на grails

Кстати, для онтопика. Связь Topic-Message - банальный one-to-one. Hibernate, а соотвественно и GORM, разруливают такую штуку без дополнительных ухищрений (разве что поле указать придется).

влияют, конечно,- около одной тысячной миллисекунды занимает вызов через метакласс (после JIT'а и прочих штук)

>одной тысячной миллисекунды

Вообще-то, это микросекундой зовётся :)

>Связь Topic-Message - банальный one-to-one
с неправильным id, правда. Я, впрочем, просто обошёл эту проблему просто сделав transient'ное поле с геттером и над ухищрениями не задумывался.

>Я правильно понимаю? :)
да. Иногда, скажем, бывают нужны только ID, а вытаскивание всех полей/связей может быть достаточно дорогим.

энивэй, возможность сделать lazy/cache/etc дописав просто [cache/lazy: true] может быть весьма полезной в некоторых случаях.

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

спасибо за информацию.

2 раза - это, конечно, многовато, но других подробностей всё равно нету.
а grails какой версии - 1.0.x или 1.1?

>Иногда, скажем, бывают нужны только ID, а вытаскивание всех полей/связей может быть достаточно дорогим.

Э...

select id from...

и

select id, title, forum_id, ... from ...

как бы по времени извлечения не должны сильно различаться. В любом случае это будет НАМНОГО экономнее ленивых последующих запросов :)

>а вытаскивание всех полей/связей может быть достаточно дорогим.

Да, я про поля, конечно. А вот связи - это в любом случае дело ленивое. Понятно, что из сообщения форума вытащить forum_id дело пренебрежимое, а вот создать объект forum() - это уже нагрузка.

Поэтому у меня forum_id() извлекается сразу, а вот forum() - метод ленивый. Либо вручную пишется, через

function forum() { return object_load('airbase_board_forum', $this->forum_id()); }

либо автоматически [есть метод, возвращающий связки вида forum => airbase_board_forum(forum_id) - понятно, что так медленнее, зато писанины ещё меньше + плюс встроенный автоматический кеш объекта].

В этом случае тоже минус есть - одно обращение к новому форуму - новый запрос (загрузка его параметров). Правда, последующие обращения к тому же объекту будут брать его уже из кеша. Но всё равно, скажем, 50 обновившихся топиков из 30 форумов. Один запрос на извлечение топиков + 30 запросов на извлечение данных из форумов.

В этом случае я делаю тупо. После извлечения топиков, выдираю из них все forum_id. И делаю пустой objects_array('airbase_board_forum', array('id' => $all_need_forums_ids)).

Будет только один запрос, который инициализирует все нужные форумные объекты и положит их в кеш.

И последующие вызовы forum() будут дёргать уже не БД, а кеш.

Итого в случае 50 топиков + 30 форумов будет не 31 запрос, а только два.

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

Смотря как компилятор сделан. По идее могут и не влиять если компилятор делает просто сабститюшен.

дык это ж метакласс, тут так просто не получился, думаю...

Вот что меня тут настораживает. Изменение байткода (а это единственный не влияющий на перформанс метод) в этом случае не проканает, т. к. расширяется класс стандартной библиотеки, и потребуется как минимум изолированный класслодер (и представьте, насколько изолированный - аппсервер пользует один java.lang.String, а приложение - другой), который еще неизвестно чем аукнется. Стало быть, скорее всего - динамические прокси. Может хотспот оптимизировать динамические прокси? Насколько я помню, нет. Но вообще, надо смотреть исходники ExpandoMetaClass.

>Изменение байткода (а это единственный не влияющий на перформанс метод) в этом случае не проканает, т. к. расширяется класс стандартной библиотеки, и потребуется как минимум изолированный класслодер (и представьте, насколько изолированный - аппсервер пользует один java.lang.String, а приложение - другой), который еще неизвестно чем аукнется

Я груви не знаю - но одним глазом глянул что такое метаклсаы. Короче по идее там все просто (ну или можно так сделать):

String.metaClass.capitalize {
StringUtils.capitalize(self);
}

компляется в что-то типа (интерфейсы я фантазирую):

MetaClasses.register(String.class, "capitalize", new Invokable() {
Object invoke(Object self) {
return StringUtils.capitalize(self);
}
}

соответственно вызов
x = "xxx"
y = x.capitalize

сабститьютится в

y = MetaClasses.lookup(x.getClass(), "capitalize").invoke(x)

разница в первомансе на хэш-лоокап.

>разница в первомансе на хэш-лоокап.

и в итоге получается около микросекунды, да

> y = MetaClasses.lookup(x.getClass(), "capitalize").invoke(x)

Это в чистом виде рефлексивный вызов. Оптимизация там такая же, как и если имена методов по отдельности выбирать.

ввиду STD09 был занят и потому почти ничего не делал, но всё-таки научился делать RSS и даже добавил на страницу с топиками:

http://thevery.info:8080/lor_grails/group/show_lastmod/19109

желающие помочь всё ещё ищутся ;)

как успехи?

пока времени нету совсем :(
мб на след. неделе перенесу ещё какой-нибудь кусок функционала/дизайна...

А почему на все ссылки 404?

если вы про http://thevery.info:8080/lor_grails - так там приложение сейчас просто не стоит (я перставлял убунту на eee pc и приложение просто не запускал). если очень надо, то могу поставить и поднять.