Ого, спасибо большое за отзыв и за стеки, не слышал про них. Вообще да, считаю любые решения должны иметь право на существование, как минимум для того, чтобы выбрать лучший для своего проекта
Да, можно было бы все тоже самое сделать полностью через Protobuf или через другие методы сериализации.
И возможно если бы у автора были бы другие результаты тестов Protobuf vs Jni, то это статья была бы не про JNI, а про то как построить полноценный RPC на базе Protobuf для Android проектов c Cmake библиотеками.
И еще вопрос, получается у вас нельзя расширять скоупы от модуля к модулю в многомодульном проекте gradle? так как константы Int просто так не передашь между подпроектами в монорепе?
Пару вопросов: Как поддерживается в такой схеме подключения кэширование тасок в Gradle? Как я понял, у вас реализация на основе BCEL? сравнивали ли с AspectJ ? И как я понимаю в любом случае планируете переписать на KSP ? И как я понимаю, чтоб добиться бОльшей оптимизации можно было бы использовать SparseArray ?
Да, вопрос хороший. Автор выбрал кодогенерацию на основе процессора аннотаций в пользу поддержки Java, а также открытости работы: можно в любой момент проследить работу в сгенерированных файлах.
KSP, Kotlin Compiler Plugin, работают только на Котлине, не генерируют промежуточный код, который можно было просмотреть.
Используется кодогенерация на основе процессора аннотаций в gradle. Валидация графа происходит на этапе компиляции, если пользоваться инжектами и провайдингом через компоненты Киллер фичи описаны на вики проекта
Тут очевидно, данных в текстовый вариант дольше сериализовать, так как нужно пройти через этап парсинга текста в число к примеру.
Спасибо@sergey-gornostaevза замечание, да в действительно заявление получилось не к месту громким.
Дополнительно хотел бы уточнить, что целей выбрать законченный RPC фреймворк - не было, и также можно было бы рассмотреть и другие доступные движки сериализации
Замеры рефлексии и сериализации отдельно уже проведены. Автор пожелал провести сравнительные замеры механизмов взаимодействия с jni библиотекой, что отображено в шапке статьи.
По бечмарку думаю можно докрутить отключение JIT оптимизации в тесте, а также оптимизацию в cmake проекте. Однако и без бечмарков и отключений оптимизаций можно делать правильные выводы в работе, если погрешности этой самой работы не ломают конечный вывод. Думаю можно дополнительно высчитывать мат. ожидание и дисперсию по результатом. Прикрутим все в работе.
Спасибо за замечание, думал прикрутить какие-нибудь замеры, к примеру hugo. Про jmh не слышал и сейчас могу отнестись скептически, так как понял, что он ломает работу с JIT и с GC, что может исказить реальное представление о скорости работы программы, но на будущее спасибо, обязательно гляну.
Однако, хотел бы также отметить, что статья не направлена на замеры бечмарк производительности кода, а проводит только "сравнительный" анализ скорости алгоритмов. Так как все замеры для всех подходов проводились в одинаковых условиях и относительная скорость работы сохраняется во всех тестах, то можно с полной уверенностью утверждать, что вывод по тестам правильный, а именно то что один подход медленнее другого.
Открыл ваш тест на GitHub и вижу там какие-то слушатели, вывод в консоль и прочее не относящееся к непосредственно сериализации
Protobuf является движком сериализации, про него и пишем, что конкретнее вы хотели увидеть?
Касательно DI - lru cache удалить обьект может по любым свои алгоритмам, не вдаваясь в подробности ЖЦ этого самого объекта. По итогу мы можем получить для обьект будет пересоздан там где не надо. Все эти кэши могут работать хорошо с однотипными обьектами, но если кэшируются различные обьекты ViewModel, Presenter, Repository, то этому самому кэшу нужно будет знать - когда можно удалять этот самый обьект, а когда нет.
Конечно идею осуществить можно, но к сожалению ее развитие зависит только от вас)
LruCache как и другие кэши inMemory с пулом основаны на идее, что обьект, который хранится в памяти не изменяется и его дубликат хранится где то еще (на диске, на сервере). При заполнении этого пула кэша до ограничения, кэш начинает выкидывать эти объекты по различным алгоритмам. Также эти обновления могут быть по триггерам (повторным загрузкам картинки с сервера)
В DI нет возможности все обьекты хранить на жестком диске, как минимум потому, что почти все обьекты, что он предоставляет недесериализуемые обьекты (не дата классы котлин).
Дополнительно добавлю. В библиотеке есть многочисленные тесты (раз и два), косвенно подтверждающие очередность удаление объектов различных ссылок. По логике библиотеки можно выстраивать очередность удаления обьектов из памяти при недостатке этой самой памяти.
Вопрос довольно открытый. Однако насколько я понимаю dalvik является частью AOSP, которая в свою очередь является открытой и обязывает ее модификации тоже делать открытыми. Для вендоров предоставляются точки интеграции (один, два и др.), которые ограничены и не позволяют ломать AOSP основы.
В тоже время существует разница в некоторых кейсах использования kotlin или java, при написании вашей программы (К примеру находил минорный кейс для Котлина). Это больше обусловлено конкретным компилятором языка, так что такое может быть встречено даже при использовании различных jdk в проекте.
Все эти кейсы уникальны и думаю на общую картину не влияют.
Спасибо за уточнение. В действительности мог допустить в этом плане некую неточность. Однако могу добавить, что JVM проводит сборку мусора над несколькими группами сегментов в памяти подробнее здесь к примеру . И получается (в теории) при долгом использовании обьектов этот самый обьект будет удаляться дольше
Идея библиотеки проста - прежде всего это избавить разработчика от необходимости определять скопы DI, заставлять джависта решать проблемы памяти, будто он использует не джаву, а плюсы. Сборщик мусора никогда не уничтожит обьект, если вы его хоть в одном месте явно используете. А значит скоупы жизни компонентов (и ЖЦ) определяются именно тем как они используются в конкретных кейсах и экранах. Более того не нужно создавать сложные скоупы для компонентов приложения, которые должны доступны с нескольких экранов, но не должны существовать весь ЖЦ приложения
Но получается, что TeaVM по подходу, это тот же самый kotlinJS.
Ого, спасибо большое за отзыв и за стеки, не слышал про них.
Вообще да, считаю любые решения должны иметь право на существование, как минимум для того, чтобы выбрать лучший для своего проекта
Да, можно было бы все тоже самое сделать полностью через Protobuf или через другие методы сериализации.
И возможно если бы у автора были бы другие результаты тестов Protobuf vs Jni, то это статья была бы не про JNI, а про то как построить полноценный RPC на базе Protobuf для Android проектов c Cmake библиотеками.
И еще вопрос, получается у вас нельзя расширять скоупы от модуля к модулю в многомодульном проекте gradle? так как константы Int просто так не передашь между подпроектами в монорепе?
Пару вопросов:
Как поддерживается в такой схеме подключения кэширование тасок в Gradle?
Как я понял, у вас реализация на основе BCEL? сравнивали ли с AspectJ ? И как я понимаю в любом случае планируете переписать на KSP ?
И как я понимаю, чтоб добиться бОльшей оптимизации можно было бы использовать SparseArray ?
Да, вопрос хороший. Автор выбрал кодогенерацию на основе процессора аннотаций в пользу поддержки Java, а также открытости работы: можно в любой момент проследить работу в сгенерированных файлах.
KSP, Kotlin Compiler Plugin, работают только на Котлине, не генерируют промежуточный код, который можно было просмотреть.
AspectJ работает только с байткодом
Используется кодогенерация на основе процессора аннотаций в gradle.
Валидация графа происходит на этапе компиляции, если пользоваться инжектами и провайдингом через компоненты
Киллер фичи описаны на вики проекта
Тут очевидно, данных в текстовый вариант дольше сериализовать, так как нужно пройти через этап парсинга текста в число к примеру.
Спасибо@sergey-gornostaevза замечание, да в действительно заявление получилось не к месту громким.
Дополнительно хотел бы уточнить, что целей выбрать законченный RPC фреймворк - не было, и также можно было бы рассмотреть и другие доступные движки сериализации
Замеры рефлексии и сериализации отдельно уже проведены. Автор пожелал провести сравнительные замеры механизмов взаимодействия с jni библиотекой, что отображено в шапке статьи.
По бечмарку думаю можно докрутить отключение JIT оптимизации в тесте, а также оптимизацию в cmake проекте. Однако и без бечмарков и отключений оптимизаций можно делать правильные выводы в работе, если погрешности этой самой работы не ломают конечный вывод. Думаю можно дополнительно высчитывать мат. ожидание и дисперсию по результатом. Прикрутим все в работе.
Спасибо за замечание, думал прикрутить какие-нибудь замеры, к примеру hugo. Про jmh не слышал и сейчас могу отнестись скептически, так как понял, что он ломает работу с JIT и с GC, что может исказить реальное представление о скорости работы программы, но на будущее спасибо, обязательно гляну.
Однако, хотел бы также отметить, что статья не направлена на замеры бечмарк производительности кода, а проводит только "сравнительный" анализ скорости алгоритмов. Так как все замеры для всех подходов проводились в одинаковых условиях и относительная скорость работы сохраняется во всех тестах, то можно с полной уверенностью утверждать, что вывод по тестам правильный, а именно то что один подход медленнее другого.
Protobuf является движком сериализации, про него и пишем, что конкретнее вы хотели увидеть?
Про раскрытие темы, спасибо за замечание
Касательно DI - lru cache удалить обьект может по любым свои алгоритмам, не вдаваясь в подробности ЖЦ этого самого объекта.
По итогу мы можем получить для обьект будет пересоздан там где не надо.
Все эти кэши могут работать хорошо с однотипными обьектами, но если кэшируются различные обьекты ViewModel, Presenter, Repository, то этому самому кэшу нужно будет знать - когда можно удалять этот самый обьект, а когда нет.
Конечно идею осуществить можно, но к сожалению ее развитие зависит только от вас)
LruCache как и другие кэши inMemory с пулом основаны на идее, что обьект, который хранится в памяти не изменяется и его дубликат хранится где то еще (на диске, на сервере). При заполнении этого пула кэша до ограничения, кэш начинает выкидывать эти объекты по различным алгоритмам. Также эти обновления могут быть по триггерам (повторным загрузкам картинки с сервера)
В DI нет возможности все обьекты хранить на жестком диске, как минимум потому, что почти все обьекты, что он предоставляет недесериализуемые обьекты (не дата классы котлин).
Дополнительно добавлю. В библиотеке есть многочисленные тесты (раз и два), косвенно подтверждающие очередность удаление объектов различных ссылок.
По логике библиотеки можно выстраивать очередность удаления обьектов из памяти при недостатке этой самой памяти.
Вопрос довольно открытый. Однако насколько я понимаю dalvik является частью AOSP, которая в свою очередь является открытой и обязывает ее модификации тоже делать открытыми. Для вендоров предоставляются точки интеграции (один, два и др.), которые ограничены и не позволяют ломать AOSP основы.
В тоже время существует разница в некоторых кейсах использования kotlin или java, при написании вашей программы (К примеру находил минорный кейс для Котлина). Это больше обусловлено конкретным компилятором языка, так что такое может быть встречено даже при использовании различных jdk в проекте.
Все эти кейсы уникальны и думаю на общую картину не влияют.
LruCache это больше про картинки, статья же про DI
Спасибо за уточнение. В действительности мог допустить в этом плане некую неточность. Однако могу добавить, что JVM проводит сборку мусора над несколькими группами сегментов в памяти подробнее здесь к примеру .
И получается (в теории) при долгом использовании обьектов этот самый обьект будет удаляться дольше
Идея библиотеки проста - прежде всего это избавить разработчика от необходимости определять скопы DI, заставлять джависта решать проблемы памяти, будто он использует не джаву, а плюсы.
Сборщик мусора никогда не уничтожит обьект, если вы его хоть в одном месте явно используете. А значит скоупы жизни компонентов (и ЖЦ) определяются именно тем как они используются в конкретных кейсах и экранах.
Более того не нужно создавать сложные скоупы для компонентов приложения, которые должны доступны с нескольких экранов, но не должны существовать весь ЖЦ приложения