Как я могу быстро создавать большие (> 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?

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

 Cheeso24 июн. 2009 г., 15:16
без акцента на изображения, как я думаю, большинство форматов изображений предварительно сжаты. Больше внимания уделяется файлам базы данных или другим двоичным потокам данных.
 Cheeso14 авг. 2012 г., 14:47
Я использовал это в тестовом наборе для DotNNetZip. Dotnetzip.codeplex.com / SourceControl / ревизия / просмотр / ...
 Kiquenet14 авг. 2012 г., 12:33
любой пример окончательного решения с полным исходным кодом?
 Sam Saffron24 июн. 2009 г., 13:34
Какие двоичные данные вы пытаетесь смоделировать (изображения)?

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

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

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

 Cheeso24 июн. 2009 г., 13:22
Я выбрал этот подход, выбрав отдельные слова из Lorem Ipsum, но генерировать большие текстовые файлы таким образом было крайне медленно. Цепной подход Маркова, кажется, склонен к строгой «естественности» текста, что для меня менее важно, чем скорость генерации.
 Noldorin24 июн. 2009 г., 13:27
епи @Markov - определенно правильный путь для этого. Они будут производить как высококачественную продукцию, так и делатьочен быстро.

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

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

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

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

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

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

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

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

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

 Dirk Vollmar24 июн. 2009 г., 13:20
Таким образом, вы могли бы получить наиболее «естественные» данные.
 Cheeso24 июн. 2009 г., 13:24
Это хороший подход для получения «естественного» текста, но если мне придется загружать 8 ГБ веб-страниц, это будет медленнее, чем подход, который я использую сейчас. Мне нравится идея.
 E Dominique24 июн. 2009 г., 14:01
Я сомневаюсь, что многопоточность сильно увеличит пропускную способность ...;)
 Benjol24 июн. 2009 г., 13:21
И ты тоже можешь скачать изображения.
 Benjol24 июн. 2009 г., 14:05
Я тоже очень удивлен всеми этими возражениями, это была шутка.

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

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

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

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

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

 Mark Rushakoff24 июн. 2009 г., 13:32
Я собирался упомянуть, что изучал проект Гутенберга. Большинство текстовых файлов уже сжаты, поэтому их быстрая загрузка. Gutenberg.org / каталог
 CesarB24 июн. 2009 г., 15:28
Существует уже тест сжатия, который использует часть дампа Википедии: Cs.fit.edu / ~ mmahoney / сжатие / textdata.html
 Sam Saffron24 июн. 2009 г., 13:49
@ Марк, хорошая мысль, я добавлю ссылку, спасибо!
Решение Вопроса

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

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

 Noldorin24 июн. 2009 г., 21:28
@ Chesso: похоже, что накладные расходы для этого связанного кода связаны с использованием IEnumerable <T> и Queues, которыеявляютс будет довольно значительным. Если вы пишете потоковый подход, производительность должна быть очень хорошей.
 Cheeso24 июн. 2009 г., 13:28
ok, я буду исследовать. Это интересно, 8 ГБ данныхраньше бы Огромный, но в наши дни, благодаря хранилищам истории веб-трафика, многотабайтным дисковым массивам, S3 и т. д., 8 Гб больше не так уж велик
 Cheeso24 июн. 2009 г., 23:40
Да, это именно то, что я нашел. Гораздо быстрее.
 Noldorin24 июн. 2009 г., 14:56
Да, это, наверное, правда. Тем не менее, с точки зрения времени вычислений и ввода-вывода, это важно даже в наши дни.
 Cheeso24 июн. 2009 г., 17:12
Правда. на цепях Маркова - я не думаю, что хочу написать новую реализацию. Impl, который я нашел, Blog.figmentengine.com / 2008/10 / марковской цепи-code.html, дал очень хороший вывод, но былочен медленный

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

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

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

Ваш ответ на вопрос