Как я могу быстро создать большой (> 1 ГБ) text+binary файлы с “естественным” содержанием? (C#)
qx начнет запись нажатий клавиш. Вы можете выполнить практически любую задачу редактирования, и Vim запоминает ее. Нажмите q еще раз, когда закончите, и нажмите @x , чтобы повторить нажатия клавиш. Это отлично подходит для повторяющихся редактирований, которые слишком сложны, чтобы написать сопоставление. Вы можете иметь много записей, используя символ, отличный от x .
8 ответов
Я думаю, вы могли бы искать что-то вроде процесса цепи Маркова для генерации этих данных. Он как стохастический (рандомизированный), так и структурированный, поскольку работает на основе конечного автомата .
Действительно, цепи Маркова использовались для генерации полуреалистичного текста на человеческих языках. В общем, их нетривиально анализировать должным образом, но тот факт, что они обладают определенными свойствами, должен быть вам достаточно хорош. (Опять же, см. Раздел Свойства цепей Маркова на странице.) Надеюсь, вы увидите, как разработать такую цепочку, однако - для реализации это на самом деле довольно простая концепция. Лучше всего, вероятно, будет создать основу для общего марковского процесса, а затем проанализировать либо естественный язык, либо исходный код (в зависимости от того, что вы хотите, чтобы ваши случайные данные эмулировались), чтобы «обучить» свой марковский процесс. В конце концов, это должно дать вам данные очень высокого качества с точки зрения ваших требований. Если вам нужны эти огромные объемы тестовых данных, стоит приложить усилия.
Для текста вы можете использовать дамп сообщества переполнения стека , там 300 мегабайт данных . Загрузка в базу данных с приложением, которое я написал, займет всего около 6 минут и, вероятно, примерно столько же времени, чтобы выгрузить все сообщения в текстовые файлы, что легко даст вам от 200 КБ до 1 миллиона текстовых файлов, в зависимости от вашего подхода. (с дополнительным бонусом в виде добавления исходного кода и xml).
Вы также можете использовать что-то вроде дампа википедии , похоже, он поставляется в формате MySQL, что упростит работу с ним.
Если вы ищете большой файл, который можно разделить для двоичных целей, вы можете использовать виртуальную машину vmdk или DVD, скопированный локально.
Править
Марк упоминает о загрузке проекта Gutenberg,
Вы всегда можете написать себе небольшой веб-сканер ...
ОБНОВЛЕНИЕ Успокойтесь, ребята, это было бы хорошим ответом, если бы он не сказал, что у него уже есть решение, которое «занимает слишком много времени».
Быстрая проверка ] здесь может означать, что загрузка 8 ГБ чего-либо займет относительно много времени.
Для текстовых файлов вы можете добиться некоторого успеха, взяв список английских слов и просто выбрав из него слова наугад. Это не приведет к появлению настоящего английского текста, но я предполагаю, что он будет давать частоту букв, аналогичную той, что вы можете найти в английском.
Для более структурированного подхода вы можете использовать цепь Маркова , обученную на некотором большом бесплатном английский текст.
Почему бы вам просто не взять Lorem Ipsum и не создать длинную строку в памяти перед выводом. Текст должен расширяться со скоростью O (log n), если вы каждый раз удваиваете объем текста, который у вас есть. Вы даже можете заранее рассчитать общую длину данных, что позволит вам не страдать от необходимости копировать содержимое в новую строку / массив.
Поскольку размер вашего буфера составляет всего 512 Кбайт или что вы его установили, вам нужно только для генерации такого количества данных перед их записью, поскольку это только количество, которое вы можете отправить в файл за один раз. Вы будете писать один и тот же текст снова и снова, поэтому просто используйте исходные 512 КБ, которые вы создали в первый раз.
Википедия отлично подходит для тестирования сжатия смешанного текста и двоичного кода. Если вам нужны сравнительные тесты, сайт Hutter Prize может предоставить высшую оценку для первых 100 Мбайт Википедии. Текущий рекорд - коэффициент 6,26, 16 мб.
Я думаю, что каталог Windows, вероятно, будет хорошим достаточно источника для ваших нужд. Если вам нужен текст, я бы рекурсивно перебрал каждый из каталогов в поисках файлов .txt и перебирал их, копируя их в выходной файл столько раз, сколько необходимо, чтобы получить файл нужного размера.
Затем вы можете использовать аналогичный подход для двоичных файлов, ища .exes или .dll.
Спасибо за быстрый ввод. Решил отдельно рассмотреть вопросы скорости и «естественности». Для создания естественного текста я объединил пару идей.
- Чтобы сгенерировать текст, я начинаю с нескольких текстовых файлов из каталога проекта Gutenberg , как было предложено Марком Рушаковым.
- Я случайным образом выбираю и загружаю один документ из этого подмножества.
- Затем я применяю Марковский процесс, как , предложенный Нолдориным , используя загруженный текст в качестве входных данных.
- Я написал новую цепочку Маркова на C #, используя в качестве примера экономичную реализацию Perl Пайка . Он генерирует текст по одному слову за раз.
- Для повышения эффективности вместо использования чистой цепи Маркова для генерации 1 ГБ текста по одному слову за раз, код генерирует случайный текст размером ~ 1 МБ, а затем многократно берет случайные его сегменты и объединяет их вместе.
ОБНОВЛЕНИЕ : Что касается второй проблемы, скорости - я решил исключить как можно больше операций ввода-вывода, это делается на моем бедном ноутбуке с мини-шпинделем со скоростью вращения 5400 об / мин. Это заставило меня полностью пересмотреть проблему - вместо того, чтобы создавать ФАЙЛ со случайным содержимым, мне действительно нужно случайное содержимое. Используя Stream, обернутый вокруг цепи Маркова, я могу сгенерировать текст в памяти и передать его в компрессор, исключив 8 г записи и 8 г чтения. Для этого конкретного теста мне не нужно проверять цикл сжатия / декомпрессии, поэтому мне не нужно сохранять исходное содержимое. Таким образом, потоковый подход помог значительно ускорить процесс. Это сокращает 80% необходимого времени.
Я еще не понял, как сделать двоичную генерацию, но, вероятно, это будет что-то аналогичное.