В какой точке стоит снова использовать массивы в Java?

Имейте в виду, что эффекты кеширования, вероятно, будут более серьезной проблемой, чем стоимость "new int [size]" и соответствующей коллекции. Поэтому повторное использование буферов - хорошая идея, если у вас хорошая временная локализация. Перераспределение буфера вместо его повторного использования означает, что вы можете каждый раз получать разные фрагменты памяти. Как уже упоминалось, это особенно верно, когда ваши буферы не подходят молодому поколению.

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

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

1. Является ли использование памяти проблемой вообще? Если это небольшое приложение, возможно, не стоит беспокоиться.

Реальным преимуществом объединения памяти в пул является избежание фрагментации памяти. Нагрузка на выделение/освобождение памяти невелика, но недостаток заключается в том, что при многократном выделении множества объектов разного размера память становится более фрагментированной. Использование пула предотвращает фрагментацию.

Когда массив больше младшего пространства.

Если ваш массив больше младшего пространства thread-local, то он напрямую выделяется в старом пространстве. Сбор мусора на старом пространстве намного медленнее, чем на молодом. Поэтому, если ваш массив больше молодого пространства, возможно, имеет смысл использовать его повторно.

На моей машине 32 кб превышает молодое пространство. Так что имеет смысл использовать его повторно.

Вы забыли упомянуть что-нибудь о безопасности резьбы. Если она будет повторно использоваться несколькими потоками, вам придется беспокоиться о синхронизации.

Я забыл, что это система управляемой памяти.

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

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

Скорее всего, вы обнаружите, что gc вообще не вызывается. Поэтому написание кода для оптимизации было бы полной тратой времени.

с сегодняшним большим объемом памяти я подозреваю, что 90% времени вообще не стоит делать. На самом деле это нельзя определить по параметрам - это слишком сложно. Просто профиль - легко и точно.

Короткий ответ: Не буферизируйте.

Причины следующие:

• Не оптимизируйте его, пока он не станет узким местом
• Если вы переработаете его, накладные расходы управления пулом будут еще одним узким местом
• Попробуйте доверять JIT. В последнем JVM, ваш массив может быть выделен в STACK, а не в HEAP.
• Поверьте мне, JRE обычно обрабатывает их быстрее и лучше, чем вы DIY.
• Сохраните его простым, для более легкого чтения и отладки

Когда вы должны перерабатывать объект:

• только если он тяжелый. Размер памяти не сделает его тяжелым, но это делают родные ресурсы и цикл процессора, которые завершают добавление стоимости и цикл процессора.
• Вы можете захотеть их переработать, если это "ByteBuffer", а не байт[]

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

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

Так что создайте свой механизм пула в качестве интерфейса и, основываясь на некотором конфигурационном параметре, выберите реализацию, используемую вашей библиотекой. Установите по умолчанию то, что ваши бенчмаркинговые тесты определят как лучшее решение.¹ И да, если вы используете интерфейс, вам придется полагаться на то, что JVM достаточно умён для встроенных вызовов.²

(1) Под "бенчмарком" я подразумеваю долгосрочную программу, которая использует вашу библиотеку вне профилировщика, передавая ей различные входные данные. Профилировщики чрезвычайно полезны, но и измеряют общую пропускную способность через час по настенным часам. На нескольких разных компьютерах с разными размерами кучи и несколькими разными JVM, работающими в однопоточном и многопоточном режимах

(2) Это может заставить вас задуматься об относительной производительности различных call опкодов.

Я думаю, что ответ, который вам нужен, связан с "порядком" (пространством измерения, а не временем!) алгоритма.

Скопируйте пример файла

По примеру, если Вы хотите скопировать файл, то Вам нужно прочитать его из входного потока и записать в выходной поток. Порядок TIME - O(n), потому что время будет пропорционально размеру файла. Но порядок SPACE будет O(1), потому что программа, которую Вам нужно будет сделать, будет иметь фиксированный объем памяти (Вам понадобится только один фиксированный буфер). В этом случае понятно, что удобно повторно использовать тот самый буфер, который вы инстанцировали в начале программы.

Свяжите политику буферов со структурой исполнения вашего алгоритма

Конечно, если вашему алгоритму нужен и бесконечный запас буферов, и каждый буфер разного размера, то, скорее всего, вы не сможете их повторно использовать. Но это дает вам несколько подсказок:

• попробуйте исправить размер буферов (даже жертвуя небольшим количеством памяти).
• Попробуй посмотреть, какова структура исполнение: на примере, если вы алгоритм проходит через какое-то дерево и вы буферы связаны с каждый узел, возможно, вам нужен только O(log) n) буферы... чтобы ты мог сделать образованная догадка о требуемом пространстве.
• Также, если вам нужны разные буферы, но вы можете договориться о том, чем поделиться различные сегменты одного и того же Массив... может быть, это лучше. решение.
• Когда вы освобождаете буфер, вы можете добавить его в бассейн буферов. Это бассейн может быть кучей, заказанной "подходящие" критерии (буферы, которые подходят больше всего должны быть первыми).

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

Надеюсь, он поможет... :)

Глядя на микротест (код ниже), на моей машине нет заметной разницы во времени независимо от размера и времени использования массива (я не публикую время, вы можете легко запустить на своей машине :-). Я подозреваю, что это потому, что мусор жив в течение столь короткого времени, что нечем заняться. Выделение массива, вероятно, должно быть вызвано вызовом calloc или malloc / memset. В зависимости от процессора это будет очень быстрая операция. Если массивы выжили в течение более длительного времени, чтобы преодолеть начальную область GC (детскую), то время для той, которая распределила несколько массивов, может занять немного больше времени.

код:

import java.util.Random;

public class Main
{
    public static void main(String[] args) 
    {
        final int size;
        final int times;

        size  = 1024 * 128;
        times = 100;

        // uncomment only one of the ones below for each run
        test(new NewTester(size), times);   
//        test(new ReuseTester(size), times); 
    }

    private static void test(final Tester tester, final int times)
    {
        final long total;

        // warmup
        testIt(tester, 1000);
        total = testIt(tester, times);

        System.out.println("took:   " + total);
    }

    private static long testIt(final Tester tester, final int times)
    {
        long total;

        total = 0;

        for(int i = 0; i < times; i++)
        {
            final long start;
            final long end;
            final int value;

            start = System.nanoTime();
            value = tester.run();
            end   = System.nanoTime();
            total += (end - start);

            // make sure the value is used so the VM cannot optimize too much
            System.out.println(value);
        }

        return (total);
    }
}

interface Tester
{
    int run();
}

abstract class AbstractTester
    implements Tester
{
    protected final Random random;

    {
        random = new Random(0);
    }

    public final int run()
    {
        int value;

        value = 0;

        // make sure the random number generater always has the same work to do
        random.setSeed(0);

        // make sure that we have something to return so the VM cannot optimize the code out of existence.
        value += doRun();

        return (value);
    }

    protected abstract int doRun();
}

class ReuseTester
    extends AbstractTester
{
    private final int[] array;

    ReuseTester(final int size)
    {
        array = new int[size];
    }

    public int doRun()
    {
        final int size;

        // make sure the lookup of the array.length happens once
        size = array.length;

        for(int i = 0; i < size; i++)
        {
            array[i] = random.nextInt();
        }

        return (array[size - 1]);
    }
}

class NewTester
    extends AbstractTester
{
    private int[] array;
    private final int length;

    NewTester(final int size)
    {
        length = size;
    }

    public int doRun()
    {
        final int   size;

        // make sure the lookup of the length happens once
        size = length;
        array = new int[size];

        for(int i = 0; i < size; i++)
        {
            array[i] = random.nextInt();
        }

        return (array[size - 1]);
    }
}