Как я могу быстро создавать большие (> 1 ГБ) текстовые + двоичные файлы с «естественным» содержимым? (С #)

Для тестирования сжатия мне нужно иметь возможность создавать большие файлы, в идеале в текстовом, двоичном и смешанном форматах.

Содержимое файлов не должно быть ни случайным, ни однородным.
Бинарный файл со всеми нулями не годится. Бинарный файл с абсолютно случайными данными тоже не годится. Для текста файл с совершенно случайными последовательностями ASCII не годится - текстовые файлы должны иметь шаблоны и частоты, имитирующие естественный язык, или исходный код (XML, C # и т. Д.). Псевдо-реальный текст. Размер каждого отдельного файла не критичен, но для набора файлов мне нужно, чтобы общий объем был ~ 8 ГБ. Я бы хотел сохранить количество файлов на приемлемом уровне, скажем, o (10).

Для создания бинарных файлов я могу создать большой буфер и выполнить цикл System.Random.NextBytes, а затем FileStream.Write, например:

<code>Int64 bytesRemaining = size;
byte[] buffer = new byte[sz];
using (Stream fileStream = new FileStream(Filename, FileMode.Create, FileAccess.Write))
{
    while (bytesRemaining > 0)
    {
        int sizeOfChunkToWrite = (bytesRemaining > buffer.Length) ? buffer.Length : (int)bytesRemaining;
        if (!zeroes) _rnd.NextBytes(buffer);
        fileStream.Write(buffer, 0, sizeOfChunkToWrite);
        bytesRemaining -= sizeOfChunkToWrite;
    }
    fileStream.Close();
}
</code>

При достаточно большом буфере, скажем, 512 Кб, это относительно быстро, даже для файлов размером более 2 или 3 Гб. Но контент абсолютно случайный, а это не то, что я хочу.

Для текстовых файлов я выбрал подходLorem Ipsum, и повторно отправлять его через StreamWriter в текстовый файл. Содержимое неслучайно и неоднородно, но имеет много идентичных повторяющихся блоков, что неестественно. Кроме того, поскольку блок Lorem Ispum очень мал (<1k), он занимает много циклов и очень, очень много времени.

Ни то, ни другое мне не подходит.

Я видел ответы на Быстро создать большой файл в системе Windows?. Эти подходы очень быстрые, но я думаю, что они просто заполняют файл нулями или случайными данными, ни один из которых я не хочу. У меня нет проблем с запуском внешнего процесса, такого как contig или fsutil, если это необходимо.

Тесты выполняются в Windows.
Вместо того, чтобы создавать новые файлы, имеет ли смысл использовать файлы, уже существующие в файловой системе? Я не знаю ни одного достаточно большого.

Как насчет того, чтобы начать с одного существующего файла (может быть, c: \ windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Config \ enterprisesec.config.cch для текстового файла) и многократно реплицировать его содержимое? Это будет работать с текстовым или двоичным файлом.

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

Кто-нибудь еще решил это?

Есть ли гораздо более быстрый способ написания текстового файла, чем через StreamWriter?

Suggestions?

РЕДАКТИРОВАТ: Мне нравится идея создания цепочки Маркова для создания более естественного текста. Тем не менее, все еще нужно противостоять проблеме скорости.

Ответы на вопрос(8)

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

Для более структурированного подхода вы можете использовать Марковская цепь натренирован на большом свободном английском тексте.

ственности» отдельно. Для создания естественного текста я объединил пару идей.

Чтобы сгенерировать текст, я начну с нескольких текстовых файлов из проект Гутенберг каталог, предложенный Марком Рушаковым. Я случайно выбираю и загружаю один документ из этого подмножества. Затем я применяю марковский процесс как предложено Нолдориным, используя этот загруженный текст в качестве ввода. Я написал новую цепь Маркова в C #, используя Экономичная реализация Perl в Pike В качестве примера. Он генерирует текст по одному слову за раз. Для эффективности вместо того, чтобы использовать чистую цепь Маркова для генерации 1 ГБ текста по одному слову за раз, код генерирует случайный текст размером ~ 1 МБ, а затем многократно берет случайные сегменты этого и объединяет их вместе.

ОБНОВИТ: Что касается второй проблемы, скорости - я выбрал подход, чтобы устранить как можно больше ввода-вывода, это делается на моем бедном ноутбуке с мини-шпинделем 5400 об / мин. Что заставило меня полностью переопределить проблему, а не генерироватьФАЙ со случайным контентом, что я действительно хочу, так это случайный контент. Используя поток, обернутый вокруг цепочки Маркова, я могу генерировать текст в памяти и передавать его в компрессор, исключая 8 г записи и 8 г чтения. Для этого конкретного теста мне не нужно проверять циклическое сжатие / распаковку, поэтому мне не нужно сохранять исходный контент. Таким образом, потоковый подход хорошо сработал для массового ускорения. Это сократило 80% необходимого времени.

Я еще не понял, как сделать двоичную генерацию, но, скорее всего, это будет что-то аналогичное.

Еще раз спасибо всем за полезные идеи.

перед выходом. Текст должен увеличиваться со скоростью O (log n), если вы каждый раз удваиваете объем текста. Вы даже можете рассчитать общую длину данных перед этим, что позволит вам не страдать от необходимости копировать содержимое в новую строку / массив.

Поскольку размер вашего буфера составляет всего 512 Кб или как бы вы его ни указали, вам нужно только сгенерировать столько данных перед тем, как записать их, поскольку это только та сумма, которую вы можете отправить в файл за один раз. Вы будете писать один и тот же текст снова и снова, поэтому просто используйте оригинальный 512k, который вы создали в первый раз.

ОБНОВИТ Успокойся, ребята, этобыло б будь хорошим ответом,есл он не сказал, что у него уже есть решение, которое «занимает слишком много времени».

Быстрая проверкаВо может указывать на то, что загрузка 8ГБ чего-либо займет относительно много времени.

свалка переполнения сообщества, там 300мг данных. Загрузка только в 6 дБ с приложением, которое я написал, и, вероятно, примерно в то же время, чтобы выгрузить все записи в текстовые файлы, которые легко дадут вам от 200K до 1 миллиона текстовых файлов, в зависимости от вашего подхода. (с дополнительным бонусом от смешивания исходного кода и XML).

Вы также можете использовать что-то вродеwikipedia dump, кажется, поставляется в формате MySQL, с которым было бы очень легко работать.

Если вы ищете большой файл, который можно разделить, для двоичных целей вы можете использовать виртуальную машину VMDK или DVD, скопированный локально.

Редактироват

Mark упоминает о загрузке проекта Гутенберг, это также действительно хороший источник для текста (и аудио), который доступен для скачать через bittorrent.

Марковская цепь процесс для генерации этих данных. Он является стохастическим (рандомизированным), но также структурированным, так как работает на основе конечный автомат.

Indeed, цепи Маркова были использованы для создания полуреалистичного текста на человеческих языках. В целом, они не являются тривиальными вещами для правильного анализа, но тот факт, что они обладают определенными свойствами, должен быть достаточно хорошим для вас. (Опять же, смотрите Свойства Марковских цепей раздел страницы.) Надеюсь, вы должны увидеть, как его спроектировать, однако для реализации это на самом деле довольно простая концепция. Лучше всего будет создать основу для общего процесса Маркова, а затем проанализировать либо естественный язык, либо исходный код (в зависимости от того, что вы хотите, чтобы ваши случайные данные эмулировали), чтобы «обучить» ваш процесс Маркова. В конце концов, это должно дать вам очень качественные данные с точки зрения ваших требований. Стоит приложить усилия, если вам нужны эти огромные объемы тестовых данных.

что каталог Windows, вероятно, будет достаточно хорошим источником для ваших нужд. Если вам нужен текст, я бы просматривал все каталоги в поисках файлов .txt и перебирал их, копируя их в ваш выходной файл столько раз, сколько необходимо для получения файла нужного размера.

Затем вы можете использовать похожий подход для двоичных файлов, ища .exes или .dlls.

двоичного кода. Если вам нужны сравнительные сравнения, Сайт Премии Хаттера может обеспечить высокую оценку для первых 100 Мб википедии. Текущая запись - 6,26, 16 м

ВАШ ОТВЕТ НА ВОПРОС