Комментарии 7
Насчет быстродействия JNA. Я как-то делал на этом взаимодействие с аж двумя нативными продуктами — с одной стороны была Windows шина Highway, заказная, специально для финансовых инструментов, со встроенным Bloomberg и поэтессами. С другой OneTick, time series база данных.
Ну я бы не сказал, что меня не устроило быстродействие. Оно вполне было сопоставимо с условным быстродействием того кода, который кладет эти же самые данные в обычную СУБД типа MS SQL. Или сильно быстрее. Зато прототип удалось выпустить за неделю. В общем все как обычно — хотите долго но эффективно — пишете на низком уровне, хотите быстро или даже тяп-ляп — берете уровень повыше. В нативном коде ничего вообще не трогал. Взял .h, написал обертку, смапив типы данных, и все заработало.
Ну я бы не сказал, что меня не устроило быстродействие. Оно вполне было сопоставимо с условным быстродействием того кода, который кладет эти же самые данные в обычную СУБД типа MS SQL. Или сильно быстрее. Зато прототип удалось выпустить за неделю. В общем все как обычно — хотите долго но эффективно — пишете на низком уровне, хотите быстро или даже тяп-ляп — берете уровень повыше. В нативном коде ничего вообще не трогал. Взял .h, написал обертку, смапив типы данных, и все заработало.
Вы сравнивали сокет и JNA, серьезно?
Почему сокет, где вы тут видели сокет? Я сравнивал, сколько я теряю быстродействия на JNA, и сколько я теряю на других взаимодействиях. Ну т.е. — если вы хотите лучшего, что можно выжать из процессора, памяти, кеша, и т.п. — то да, JNA вам наверное не самый лучший выбор — так вам тогда и Java наверное не очень нужно. Но если вам интегрироваться с неким продуктом, у которого кроме C API ничего и нет — то вы это сделаете быстро, и не слишком много потеряете по сравнению с условным SQL-запросом к базе.
У нас была торговля. Биржевая. Не HFT, отнють. И вообще бонды. Поток сделок с московской биржи переваривало, без всяких проблем вообще.
У нас была торговля. Биржевая. Не HFT, отнють. И вообще бонды. Поток сделок с московской биржи переваривало, без всяких проблем вообще.
Очень интересное сравнение технологий. Спасибо автору. Очень познавательно.
Если сначала сработает финализатор Memory, то мы чистим память, адрес на которую записан в addr. Затем переходим в финализатор StringByReference, где не делаем ничего, т.к. в addr уже лежит null
Интересно, почему это так работает? Если технически объект addr еще доступен для StringByReference, то почему для него уже вызвался финализатор?
Имеется в виду ситуация, когда оба объекта — и StringByReference и Memory уже недоступны из root-ов, но один из них ссылается на другого.
В этот момент уже пора вызывать финализаторы, т.к. уже пора собирать оба эти объекта. Иначе мы бы столкнулись с проблемой циклического мусора: могла бы быть пара объектов A <-> B, ссылающихся друг на друга, но ниоткуда больше недоступных. Если ждать, пока ссылки пропадут совсем, то они так навсегда и осядут в куче, ведь ссылки на каждый из этих объектов будут всегда. Трассирующие GC как раз решают эту проблему, проверяя достижимость от корневых объектов.
В этот момент уже пора вызывать финализаторы, т.к. уже пора собирать оба эти объекта. Иначе мы бы столкнулись с проблемой циклического мусора: могла бы быть пара объектов A <-> B, ссылающихся друг на друга, но ниоткуда больше недоступных. Если ждать, пока ссылки пропадут совсем, то они так навсегда и осядут в куче, ведь ссылки на каждый из этих объектов будут всегда. Трассирующие GC как раз решают эту проблему, проверяя достижимость от корневых объектов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В нативный код из уютного мира Java: путешествие туда и обратно (часть 2)