Доступ к кешу в C через JNI - PullRequest
3 голосов
/ 05 апреля 2011

Имеет ли смысл с точки зрения повышения производительности создавать кеш типа LRU в C / C ++ и получать java для доступа к нему через JNI?

Ответы [ 4 ]

6 голосов
/ 05 апреля 2011

Сомнительно

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

Не говоря уже о трудностях разработки, обслуживания и развертывания кода C ++ по сравнению с Java.Или опасность переизобретения колеса путем развертывания собственного кэша - там должно быть что-то, что вы могли бы использовать вместо того, чтобы выкатывать свой собственный.

4 голосов
/ 05 апреля 2011

Вы почти наверняка не оптимизируете правильную вещь здесь. Реализация кеша редко , что требует оптимизации в большой системе. Есть много хороших и быстрых реализаций для Java. Вы вряд ли получите что-то лучшее из нативной реализации. И даже если бы вы могли, вы уверены, что действительно это нужно?

Обычно все, что вы делаете с кешем, на самом деле имеет значение. Запросы к базе данных, блокирующие операции и задачи с интенсивным использованием процессора. Вы, безусловно, должны профилировать свое приложение и оптимизировать только те области, которые в нем нуждаются. Если вы оптимизируете что-то, что занимает всего 5% от общего времени, то вы получите улучшение только на 5% в лучшем случае (то есть, если вы сделали это бесконечно быстро).

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

1 голос
/ 05 апреля 2011

маловероятно.

Кеш работает с объектами в куче. Распределение и освобождение кучи памяти в C ++ не лучше, чем в Java. Фактически, в кратковременном тесте кэш Java, вероятно, даже выиграл бы из-за отложенного GC (C ++ должен освобождать память явно и немедленно).

Ожидается, что другие операции (put, find) будут наравне с C ++ из-за JIT (это горячие точки, и скоро они будут скомпилированы в собственный код).

Примечание: как всегда с производительностью, окончательный ответ может быть получен только с помощью тестов.

1 голос
/ 05 апреля 2011

JIT-компилятор чертовски быстр. Конкурирует скомпилированный код.

Лучше всего внедрить его в то, что проще всего разработать, а затем профилировать его для выявления проблем с производительностью. Затем посмотрите, что вы можете сделать оттуда.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...