Здравствуйте, f95.2, Вы писали:

F2>Судя по всему, о ней вообще не думают...

Думают об алгоритмах. Думают о конкретной реализации, если очевидно, что данных очень много. Т.е. если ты реально будешь сериализовать объект в гигабайты, там да, можно и массив массивов сварганить (стандартного класса нет, в других библиотеках не видел такого).

О том, чтобы избежать копирования нескольких килобайтов — нет, не думают. По крайней мере пока профайлер не покажет пальцем на этот код.

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

F2>Так проблема возникла. Просто заключается она не в том, чтобы код написать и ускорить, а в том,
F2>чтобы разобраться, какие есть типовые варианты решения и какие у них плюсы и минусы.

Типовой вариант решения это ByteArrayOutputStream. А то, что он там копирует, это уже не твои проблемы. Реально он воде каждый раз в 2 раза буфер увеличивает, т.е. копирований будет логарифм от максимального размера, т.е. немного. Такого, что на каждый записанный байт будет заново копироваться не будет, квадратичного роста времени выполнения здесь нет.

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

Это я к подходу Java подвожу (: Не руками всё делаем, а слепливаем решение из готовых библиотек.

При этом, конечно, понимать, что происходит в твоём коде, надо.

Здравствуйте, f95.2, Вы писали:

F2>Судя по всему, о ней вообще не думают...

Думают об алгоритмах. Думают о конкретной реализации, если очевидно, что данных очень много. Т.е. если ты реально будешь сериализовать объект в гигабайты, там да, можно и массив массивов сварганить (стандартного класса нет, в других библиотеках не видел такого). Хотя там уже лучше думать о том, как это всё передать не накапливая данные в памяти.

О том, чтобы избежать копирования нескольких килобайтов — нет, не думают. По крайней мере пока профайлер не покажет пальцем на этот код.

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

F2>Так проблема возникла. Просто заключается она не в том, чтобы код написать и ускорить, а в том,
F2>чтобы разобраться, какие есть типовые варианты решения и какие у них плюсы и минусы.

Типовой вариант решения это ByteArrayOutputStream. А то, что он там копирует, это уже не твои проблемы. Реально он воде каждый раз в 2 раза буфер увеличивает, т.е. копирований будет логарифм от максимального размера, т.е. немного. Такого, что на каждый записанный байт будет заново копироваться не будет, квадратичного роста времени выполнения здесь нет.

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

Это я к подходу Java подвожу (: Не руками всё делаем, а слепливаем решение из готовых библиотек.

При этом, конечно, понимать, что происходит в твоём коде, надо.