|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Добрый вечер, уважаемые ! Стоит вот задача разбора и анализа логов. Несмотря на то что файлы логов ежедневно создаются новые размер дневного лога вполне может достигать 200-300 Мб. Из этого объема информации надо вычленить нужную мне и выгрузить в отдельный файл. Логи пишутся сторонней программой. В принципе прослеживается определенная структура в виде заголовков строк. В чем заковыка. Разработчики дают прогу разбора лога, но без возможности выгрузить информацию. За возможность ткнуть мышкой в нужное событие и выгрузить в отдельный файл информацию просят денежку или сиди делай копипаст. У них эта прога разбирает файл 55 мб по событиям за 12 секунд. Если я просто пройдусь по этому файлу Код: plaintext 1.
то уже потрачу 24 секунды. а нужно еще и проанализировать и выгрузить. Если я загоняю информацию построчно в mdb на это тратится порядка 4 минут, что уже совсем не айс. А отчеты приходится делать за период до 2-3 лет. Т.е Информации море. Подскажите может есть более шустрые методы обработки таких объемов текстовой информации? Может можно файл загнать в память и там переварить? Или может кто решал аналогичные задачи? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 19:38 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, Можно конечно считать сразу весь файл Код: plaintext 1.
в память а дальше его как обрабатывать? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 19:44 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
пример лога опубликуй возможно, самый быстрый способ будет - загрузить его в mdb через odbc ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 19:54 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Shocker.Pro, не знаю будет ли это достаточным. Вот кусок описывающий одно событие. Для краткости содержимое секций убрал. В секциях XML описание событий (это описание разбирать не требуется). Нужно выловить из череды событий нужное исходя из содержимого секции UserInfo. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 20:10 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
а-а-а... то есть исходник не текст, XML? тогда я пожалуй помолчу, ибо опыт маловат ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 20:20 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menДля краткости содержимое секций убрал.Лучше вернуть. Если исходные данные это xml, то при применении xsl 12 секунд на 55 мегов кажутся черепашьей скоростью. Впрочем, я сейчас на шустром железе. Формат решает всё. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 20:36 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Текстовые логи удобнее разбирать на awk, и по скорости работы его побить невозможно. Главный учебник здесь: http://www.gnu.org/s/gawk/manual/gawk.html Виндовых версий море, лучше взять вот эту: http://gnuwin32.sourceforge.net/packages/gawk.htm ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 21:20 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
можно приблизительно оценить скорость с какой это можно сделать скорость современного диска на чтение 30 мбайт\сек для файла 300 мбайт получается 10 сек те чтобы загрузить в память весь 300 мбатный файл надо всего лишь 10 секунд прочитать всю память размером 1гигибайт грубо говоря можно за секунду так что возможно сделать то что нужно достаточно быстро к сожалению из формулировки вопроса не понятен формат файла но алгорим такой 1 выделить 300 мбайт памяти 2 прочитать в нее весь файл 3 можно читать по кусочам и это не замедлит общее время просто мороки больше а 300 мбайт свободных есть на любом нормальном компе на сегодняшний день 4 сканируем побайтно память пока не найдем искомую строку как я понимаю ("UserInfo") 5 парсим дальше как надо то что a.readline занимаем 24 секунды означает что неверный алгоритм программы ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 22:53 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
если алгоритм парсера простой то проше сделать все вручную чем искать и смотреть проги ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 22:55 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Shocker.Pro, Исходник это текст. просто часть секций описывает действия пользователя (доступ и работу с сайтом) в XML, а часть описывает реакцию системы текст. Так что в целом лучше рассматривать как текст. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 08:27 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерможно приблизительно оценить скорость с какой это можно сделать скорость современного диска на чтение 30 мбайт\сек для файла 300 мбайт получается 10 сек те чтобы загрузить в память весь 300 мбатный файл надо всего лишь 10 секунд если дать команду Код: plaintext 1.
то файл в 55 метров загрузится в память за 8 секунд. Возможно у меня машинка не самая мощная, и винты еще IDEшные. но как говорится что имеем. парсерпрочитать всю память размером 1гигибайт грубо говоря можно за секунду так что возможно сделать то что нужно достаточно быстро к сожалению из формулировки вопроса не понятен формат файла но алгорим такой 1 выделить 300 мбайт памяти 2 прочитать в нее весь файл 3 можно читать по кусочам и это не замедлит общее время просто мороки больше а 300 мбайт свободных есть на любом нормальном компе на сегодняшний день 4 сканируем побайтно память пока не найдем искомую строку как я понимаю ("UserInfo") в этом направлении сейчас и буду копать. Вся фишка в том что это всего лишь 3-я моя программа на VB, поэтому не все полезности мне известны. Например как прочить файл в память я нашел. А вот что потом в памяти с ним делать пока не знаю :( ни как сканировать ни как выгружать куски загруженного файла. выгружать мне надо не только секцию ("UserInfo"), а весь Фрагмент лога от "IncomingTime" до "OutgoingTime" который содержит в себе секцию ("UserInfo") с параметром "Иванов Иван Иванович". Так что помимо найти секцию мне надо еще перейти на начало фрагмента IncomingTime и выгрузить весь фрагмент целиком до "OutgoingTime". А затем продолжить поиск парсер5 парсим дальше как надо то что a.readline занимаем 24 секунды означает что неверный алгоритм программы :) я приведу код процедуры, которой я проводил оценку, а вы пожалуйста где косяк :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 08:49 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, ну собственно алгоритм примерно такой : -------------> Читаем файл <----------------------- | | | | если нашли UserInfo с заданным критерием--нет -- | | | да | | | выгружаем фрагмент в файл результат | | -----нет--- если читаемый файл EOF ^ | | да | | | есть ли еще файлы-------------нет---------- | | | | да конец программы | | -------- переходим к следующему файлу ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 09:03 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Извиняюсь забыл про пробелы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 09:08 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, Неужели скорость так важна? может зря бьетесь за этот параметр? Уже несколько лет сопровождаю ПО которое загружает кучу логов, отчетов, данных из других БД, и на все это требуется до 3-х дней, а после еще полдня на генерацию нужных отчетов, но пользователям этот цикл нужно повторять один раз в месяц, поэтому даже 4-5 дней для них не проблема, хотя от некоторых и слышу - загрузка таких-то данных длилась 8 часов, можли ли ускорить, такое впечатление, что они уголь 8 часов грузили, поэтому когда спрашиваю для чего, то ни кто из них объяснить не может, по факту - запустили и забыли. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 10:32 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
novexelf, К сожалению важно. Информация по логам предоставляется 5-10 раз в месяц за различный период (до 5 лет, а это примерно 10 гиг текста в год и больше). пока запрос доходит до меня из-за бюрократии теряется от 4 часов до суток, а на подготовку дается 3 дня с момента отправки запроса. при этом возможно одновременное поступление нескольких запросов. Вот недавно пришел запрос информации за 3 года. разбору подлежало 34 гига текста. Та программка что у меня была давно на akse разбирала это около 2 и 1/2 -суток на очень хорошей рабочей станции. Хочу сократить время хотябы раза в 3 время на разбор и при этом чтобы работало на средней по мощности рабочей станции, тем более что анализатор разработчиков дразнит скоростью капитально. Как я уже говорил за 12 секунд он считывает файл в 55 МБ и разбирает его по деталям. Можно смотреть информацию в разрезе пользователя, или в разрезе сессии, или по времени событий... Только выгрузки не дает и потоковости обработки. Моя же нынешняя прога будет возится с тем же файлом по указанному алгоритму примерно 4-5 минут. Разница очевидна ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 11:02 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, есть еще одна заковыка. не знаю из каких соображений но у разработчиков в логах встречаются строки по 67-70 тыс символов. Тут уже и мемо поля не помогут рубить будет :( ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 11:08 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Если речь идет о VB, а не о VBS, то FileSystemObject не нужен. VB умеет сам работать с файлами. Open/Get/Input/Close. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 11:28 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, Насколько я понял, у вас файл xml, некоторой структуры, так почему бы не подвязать его к акссесу? это будет явно быстрее, чем парсить самостоятельно, ну и после можно будет запрос выполнить ... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 11:46 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
novexelf, XML не во всех секциях и мне его разбирать не надо мне его надо выгрузить вот например секция : [2011.11.28 00:54:45:730][TraceID: TWDPWCC8R36HNU]->IncomingData\706 FЪКД2 TWDPWCC8R36HNU P Connection: Keep-Alive Accept: text/html, application/xhtml+xml, */* Accept-Encoding: gzip, deflate Accept-Language: ru-RU Cookie: exp_path=C%3A%5CUsers%5C%u0412%u0430%u0434%u0438%u043C%5CDesktop; __utma=179010226.226380545.1311577166.1321904062.1322427283.33; __utmz=179010226.1311577166.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=179010226.1.10.1322427283; SID=6a58efcbb44bba88asdb9bb087; hotlog=1; __utmc=179010226 Host: www.тра-та-та.ru Referer: http://www.тра-та-та.ru/ User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; BOIE9;RURU) T=R_Loader.Load7 # RequestInfo=12.16.1.5|12.16.1.9 ccSITE=R ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 12:08 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85.
я предположил что конец и начало строки это границы на которых надо извлечь данные только если будет очень много записей (100 000) то понятно что экспорт их даже с текст файл затормозит прогу а простое сканирование выполняется быстро ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 15:49 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
по поводу btn_search_Click 1 тормозит вызов readLine тк при каждом вызове выделяется память для возвращаемой строки когда строк 1 000 000 это очень тормозит поэтому память надо выделять только один раз эта главная причина 2 тормозит DoEvents насколько томозит не знаю можно замер сделать ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 15:54 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Строк в файле на 55 Мб получается порядка 850 тыс. Занялся изучением вопроса управления выделяемой памятью. Спасибо за код сел разбираться. по поводу Код: vbnet 1.
я уже нашел и промерил. для того же выше указанного цикла с простым ReadLine, если DoEvents делать не каждый раз (я сделал раз в 100 циклов) время сократилось с 24 сек до 8. Дальнейшее увеличение количества циклов, когда DoEvents не отрабатывает, на скорость не повлияло, а вот попасть по кнопке "стоп" становится проблемно. Спасибо Вам за помощь. Ничего если будут вопросы еще поуточняю кое чего? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 16:30 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
спрашивайте я думаю можно просто запустить Test02 для лог файла и посмотреть что получится ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 16:59 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Просто запустить это я конечно сделаю. Но мне важно еще и самому разобраться и понять что и как там внутри тикает. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 17:13 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Кстати сходу не распознает Код: vbnet 1.
У меня VB6. Если в MSDN пока нашел описание для VB.NET ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 17:27 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
все верно просто под отладчиком по-моему удобнее смотреть только файл тестовый тогда маленький надо создать чтобы не ждать в подходе a.readline есть такая проблема строку Вы прочитали а дальше с ней что-то надо делать а делать можно только с помощью vb функций а они для данной задачи не подходят даже если просто писать что-то типа if mid(str, 1, 1)="A" then те брать символ из строки и потом его анализировать то будет очень долго тк строк порядка милилиона и каждая строка порядка сотни сиволов чтобы избежать этого я использую встроенную функцию InStr InStrRev они делают то же сканирование но быстро ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 17:28 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Attribute VB_Name = "FileParseM" это просто не надо писать в файле но бейсик сам дописывает эту строку откройте нотепадом Ваш файл и увидите то же для любого файла vb ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 17:30 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Прошу прощения а Вы код не вредакторе пишите? Находит быстро, вот я только зря msgbox не заремил :) и doevents не вставил :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 17:50 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
конечно в редакторе. просто после сохранения я выбираю файл в списке файлов проектов и делаю экспорт. тк я в офисе именно этот пример писал. а в vb6 понятно файл сразу готов. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 18:07 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, А вот интересно если парсить в буфере. могу я по мере прохода по буферу повесить на некую строку метку (или запомнить ее позицию) чтобы потом на нее перейти если содержимое секции UserInfo удовлетворяет заданному критерию? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 18:19 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Test02 работает так 1 находит строку "UserInfo" 2 находит символ новой строки сканируя строку в обратном направлении 3 находит символ новой строки сканируя строку в прямом направлении 4 повторяет это до конца файла соответственно у нас есть позиция начала и конца найденного участка с UserInfo я не знаю формат файла поэтому я могу знать правильно ли это. может UserInfo буфер может содержать символы новой строки. но тогда надо просто начало и конец искать по тем сиволам которые указывает на начало и конец записи UserInfo Когда мы нашли запись с UserInfo мы можем ее обратотать так как нам нужно Если хотим можем запомнить начало и конец буфер как смещение от начала файла то это lngLineBeginPosition lngLineEndPosition Опять же самый быстрый метод обработки когда мы найденный буфер сразу анализируем и экспортируем куда нужно если требуется Просто если запомнить позиции начала конца а потом дополнительно опять как-то обработать найденные записи то получим увеличение времени тк дополнительно время будет тратиться 1 на сохранение найденных позиций в новом файле 2 на чтение найденных позиций из нового файла 3 на чтение найденных записей из исходного файла используя прочитанные на предыдущем шаге позиции начала конца файла ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 19:09 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, Для работы с большими текстовыми файлами надо использовать регулярные выражения. (Если VB не поддерживает надо подключить к библиотеку Microsoft VBScript Regular Expression 5.5) Думаю в программе, за модификацию которой требуют деньги, они используются. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 08:16 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
gacolДля работы с большими текстовыми файлами надо использовать регулярные выражения. Чушь. Никакой связи между размером файла и использованием регулярных выражений нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 09:06 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alibek B., Регулярные выражения придумали специально для ускорения работы с большими текстами, они зайствованы во многих редакторах Или мы про разное говорим? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 10:13 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Нет. Регулярные выражения используются для сложных манипуляций с текстом. Объемы текста никак с этими манипуляциями не соотносятся. Более того, регулярные выражения применимы не всегда, в некоторых случаях (когда нужен стек или когда объемы текстов очень большие) лучше использовать конечные автоматы или потоковую обработку. В случае с XML остаются автоматы без вариантов. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 10:28 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Добрый день! А почему выбран бинарный метод обращения к файлу? И я всетаки не очень понимаю Чем OPEN лучше чем работа с FSO? в принципе я так понимаю во втором случае дополнительно надо объявлять переменные, что чуток больше ест ресурсы. может еще есть причины? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 12:08 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, и еще если доступ к файлу открыть в режиме READ пошустрее не будет? или есть ньюансы в работе команды OPEN?(просто из аналогии с ADODB вопрос) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 12:10 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
файл можно читать любой функцией если помимо чтения надо еще какие-то операции делать с файлами фолдерами то FileSytemObject может быть и удобнее тк в нем много нужных функций для работы с файлами каталогами если заранее известно что файл текстовый то можно его открывать как текстовый но надо помнить что если в файле открытом как текстовый встретятся какие-то специальные управляющие символы то они будут рассматриваться как управляющие ну и размер считанной строки не совпадет с длиной файла тк символы начала строки преобразовываются ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 12:36 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menЧем OPEN лучше чем работа с FSO? Тем, что FSO — лишняя прослойка. Ну и тем что FSO загружает файл только в строку, а OPEN позволит загрузить файл в байтовый массив. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 14:39 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alibek B., Клевета на FSO :) Никто не мешает сделать так: Код: vbnet 1.
при этом весь файл будет загружен в строковую переменную ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 16:45 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alibek B., тут скорее будет загвозка как сказал Парсер: парсересли заранее известно что файл текстовый то можно его открывать как текстовый но надо помнить что если в файле открытом как текстовый встретятся какие-то специальные управляющие символы то они будут рассматриваться как управляющие ну и размер считанной строки не совпадет с длиной файла тк символы начала строки преобразовываются И то я думаю можно поисследовать этот вопрос. Я за неимением времени исследование отложу покамест, и воспользуюсь предложенным выше примером кода (да и интересно я с буфером первый раз работаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 16:50 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menпри этом весь файл будет загружен в строковую переменную А я с этим спорю? Но байтовый массив эффективнее, чем строковая переменная. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 16:56 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menно надо помнить что если в файле открытом как текстовый встретятся какие-то специальные управляющие символы Какие? Есть только два специальных управляющих символа (0x0D, 0x0A), которые отмечают конец строки. Другие символы ничем не мешают. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 16:58 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alibek B., Не буду спорить, т.к. я этот вопрос только изучаю. Покамест вродебы получается весьма шустро. А вот кстати нет ли какойнибудь развернутой статейки на эту тему? а то в стандартном учебнике я что то мало что почерпнул. Единственное надо поискать по метке "массивы". может это что еще подскажет. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 17:11 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Прочитай эту тему: http://bbs.vbstreets.ru/viewtopic.php?f=1&t=43464 Только прочитай до конца. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 17:22 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alibek B., Спасибо, а вот сходу вопрос. отобрал я нужный мне кусок лога. Могу я его сразу куском влить в текстовый файл? или писать всетаки надо построчно? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 17:41 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Можно сразу куском. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 17:53 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
УХ ты! Провел сравнительный тест на файлике в 55 Мб. Старая моя прога 4 минуты 43 секунды. С Вашей помощью, новая 1 минута 50 сек. Это конечно не 12 секунд, но более чем двукратное сокращение времени, плюс более точная выгрузка информации это уже не плохо. На всякий случай Если Вас не затруднит гляньте код, межет можно упростить, а следовательно и ускорить. Смущают меня пара моментов. Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 18:58 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
насколько я понял формат строки для поиска такой >IncomingTime***UserInfo***LineEnd где *** любые символы мне не нравится такое большое время что-то не так 1 сколько в итоге находится записей нужных? 2 сколько времени занимает поиск если находить только UserInfo те оставить только это остальное закоментить CriteryPosition = InStr(lngCurrentPosition, strBuffer, strUserInfo, VbCompareMethod.vbTextCompare) - оставить эту строку закоментить тоже для этого пункта strFound = Mid(strBuffer, LnBeginSectionPos + Len(strLineBegin), LnEndSectionPos - LnBeginSectionPos - Len(strLineBegin)) - закоментить 3 "Смущают меня пара моментов" каких? я когда тестировал создал файл 100 мб и одну запись UserInfo так он читался 15 сек пока я не вижу откуда появляется столько дополнительного времени ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 19:53 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
вообще надо внутренность Do while loop закоментить а потом по логичестким кускам раскоментить чтобы понять какие куски тормозят при большом количестве найденных записей может тормозить strFound = ... ну и конечно запись в файл но все равно не настолько диск читается в несколько раз быстрее чем пишется но это 2-4 раза а тут все 10 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 20:01 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
1) Mid заменить на Mid$ 2) Do While lngCurrentPosition <= Len(strBuffer) заменить на Do While lngCurrentPosition <= lngBufferLength Хоть Len и быстрая функция, лучше лишний раз не дергать, если можно не дергать. 3) Тынц ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 20:49 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Если для анализа достаточно LIKE, присмотрись к Hytech. скорость лайка на больших строках и больших количествах за гранью разумного :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 22:00 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
проверил то что предложил Antonariy действительно vbTextCompare тормозит можно по указанной ссылке взять функцию которая нормально работает а может в нашем случае можно vbBinaryCompare использовать вряд ли лог файл по-разному пишет ключевые слова to pureproft Если для анализа достаточно LIKE, присмотрись к Hytech. не понятно что значит LIKE, присмотрись к Hytech ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2011, 23:35 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерпроверил то что предложил Antonariy действительно vbTextCompare тормозит можно по указанной ссылке взять функцию которая нормально работает а может в нашем случае можно vbBinaryCompare использовать вряд ли лог файл по-разному пишет ключевые слова to pureproft Если для анализа достаточно LIKE, присмотрись к Hytech. не понятно что значит LIKE, присмотрись к Hytech google 1-й строчкой дает hytechdb.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 00:35 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menУХ ты! Провел сравнительный тест на файлике в 55 Мб. Старая моя прога 4 минуты 43 секунды. С Вашей помощью, новая 1 минута 50 сек. Это конечно не 12 секунд, но более чем двукратное сокращение времени, плюс более точная выгрузка информации это уже не плохо. А теперь интереса ради, посмотри все же на AWK. Скачай вот это: http://gnuwin32.sourceforge.net/packages/gawk.htm и запусти вот это: Код: sql 1. 2. 3.
Сохрани этот текст как test.awk, в первой строке замени "some user name" на то что должно находится в твоей переменной strUserInfo, и запусти его из командной строки: Код: vbnet 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 01:29 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
to pureproft Hytech я так понял что это бд а нужно просто из файла один раз извлень данные по критерию to White Owl это то что нужно не знаю сложно ли освоить синтаксис но прога делает то что нужно и с максимально возможной скоростью ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 02:46 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
тут пока я пытался опредилить время выполнения возник такой вопрос как удалить из файлового кеша файл а то файл раз читается с диска а все следующие разы читается из памяти что не дает возможности замерять реальное время ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 02:48 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Значится попробую по порядку: 1) По заданному критерию найдено 35 фрагментов общим объемом 4246 строк. строки от10 символов до 70 тыс символов. Так что вполне возможно 2) Пробовал отключить все что связано с выгрузкой в файл получил разницу в 1 секунду. Кстати на средней машинке в офисе выполнение идет вообще 5 минут. 3) По алгоритму. Мне надо вытаскивать фрагмент произвольного количества строк от "[дата время]->IncomingTime" до "[дата время]->OutgoingTime". секция "UserInfo" состоит из 2-х строк во второй как раз и прячется искомый параметр собственно юзер "ИВАНОВ ИВАН ИВАНОВИЧ". 4) по gawk систему скачал, пока еще не изучил. Вопрос сразу, мне нужно обрабатывать массив ежедневных логов чаще всего за год полтора это порядка 500-600 файлов. Gawk позволяет поток обработки организовать 5) остальные предложения по коду сейчас буду пробовать. Сейчас в первую очередь вот что сделаю попробую сбросить strFound сразу после вывода информации. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 08:52 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсертут пока я пытался опредилить время выполнения возник такой вопрос как удалить из файлового кеша файл а то файл раз читается с диска а все следующие разы читается из памяти что не дает возможности замерять реальное времяНе трать время на ерунду, тебе не нужно знать реальное время, все компьютеры разные. Тебе нужно знать разницу между несколькими вариантами алгоритма. Я для этого вообще считываю все данные в память, чтобы операции ввода-вывода не вносили искажений, и прогоняю алгоритм в цикле несколько раз. Еще есть профайлер VB Watch 2 , который умеет замерять время каждой операции, суммирует это время, и на красивых понятных гистограммах показывает, какие строчки наиболее тормозят. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 10:01 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерпроверил то что предложил Antonariy действительно vbTextCompare тормозит можно по указанной ссылке взять функцию которая нормально работает а может в нашем случае можно vbBinaryCompare использовать вряд ли лог файл по-разному пишет ключевые слова Эврика замена vbTextCompare на vbBinaryCompare сократило время до 1 секунды причем на средней офисной машине, где проход занимал 5 минут 42 секунды. Судя по объему файла результата точность не изменилась. Сейчас сверю то что отбирается с исходным файлом и если все хорошо включу потоковую обработку и разомнусь для начала на 1 Гб логов. Ой Ребята СПАСИБО!!! Правда мне еще кое чего надо разобрать до косточки, но тут уж интернет мне поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 10:34 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Antonariy1) Mid заменить на Mid$ Спасибо за ссылочку этим инструментом не пользовался. А еще подскажите чем отличается Mid заменить на Mid$. В хелпе я нашел только MID и MIDB. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 10:37 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
> Автор: Alex_men > А еще подскажите чем отличается Mid заменить на Mid$. Тем, что Mid работает с типом Variant, поэтому более универсальна, но за универсальность нужно платить, в данном случае - быстродействием. А Mid$ работает сразу с типом String и поэтому более скорострельна. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 11:36 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Игорь Горбонос, Спасибо! А где можно почитать про такие нюансы? Я что то в хелпе такого не нашел. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 12:29 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
> Автор: Alex_men > А где можно почитать про такие нюансы? Да вот так на форумах и всплывают такие ньюансы :) На том-же bbs.vbstreets.ru раньше(в годах 2001-2005) было много таких топиков, пока я бывал там и активно участвовал. :) Поспрошай там Хакера, может он накидает тебе ссылок на интересные темы :) Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 12:35 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Проблемка нарисовалась. При попытке поместить в память файл объемом 160 Мб. Вылетает OUT OF MEMORY. Вот была ссылочка по чтению больших файлов, попробую там чего найти. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 12:51 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторразомнусь для начала на 1 Гб логов боюсь что для файлов такого размера ничего не получится уж слишком большой размер если файл в память не поместиться система его будет в файл подкачки грузить те получим только увеличение работы с диском хотя опять же главное эксперимент если есть 3Г свободной то может и все нормально будет иначе придется изменить процедуру чтобы она по частям файл читала рекомендую посмотреть и gawk я попробовал сделать то что написано не разбираясь так она действительно работает очень быстро и главное то что это одно из предназначений этой проги те прога как раз для этого написана и еще один момент можно улучшить прогу если заменить работу со строкой на на работу с массивом байт те Dim strBuffer as String заменить Dim bytBuffer() as Byte strBuffer = String(0, Length) -> ReВim bytBuffer(Length - 1) и функции InStr, InStrRev, Mid заменить на InStrB, InStrRevB, MidB "B" как раз и означает байт других изменений не нужно Отличие в следующем когда мы читаем строку то из файла читается один байт символ потом он преобразовывается в двухбайтный символ Unicode и сохраняется в строке те строка из 1000 символов будет занимать 2000 байт при таких огромных размерах логов мы существенно экономим память правда я не думаю что это ускорит прогу тк разница во времени сканирования 1Г или 2Г практически нулевая ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 13:04 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
вот определил на своем компе 1 строка выделяется размером 300Мб размером 400Мб уже не хочет 2 массив байтов выделяется размером 600Мб размером 700Мб уже не хочет ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 13:22 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, с AWK смотрю но по указанному алгоритму у меня ничего не находит, хотя и отрабатывает быстрою результат =0. А как файл кусками читать. или вот еще нашел можно проекцию создавать и работать с ней ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 13:23 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, что такое ReBim? не требует ли дополнительного определения или подключения в референсах? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 13:34 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menчто такое ReBim?это ReDim, видимо ) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 13:45 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
ReDim опечатка а чтобы читать по кускам нужно немного изменить функцию если у нас только часть файла загружена то здесь CriteryPosition = InStr(lngCurrentPosition, strBuffer, strUserInfo, VbCompareMethod.vbTextCompare) 'MsgBox CriteryPosition If CriteryPosition = 0 Then Exit Do End If уже не надо выходить а просто прочитать следующий кусок If CriteryPosition = 0 Then FileRead position, strBuffer End If единственно что нужно учесть это то что какой-то кусок у нас остался не проверенный LnEndSectionPos позиция последней найденной записи а кусок от LnEndSectionPos до BufferSize не исследован поэтому надо этот кусок поместить в начало буфера в диапазон [0, BufferSize - LnEndSectionPos] и читать следующий кусок записывая данные в диапазон [BufferSize - LnEndSectionPos, BufferSize] вот и все остальное без изменений итак FileRead теперь объявлена так FileRead (ByRef strBuffer as string, byval lngBufferSize as long, byval lngBufferPosition as long) буфер надо выделять заранее и потом передавать во все функции ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 13:49 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
gawk может не работать из-за того что условие вероятно подразумевает что строка одна те символ новой строки является разделителем это и есть недостаток этой проги что сначала надо узнать синтаксис для построения верного запроса сам я не пытался синтаксис читать ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 13:52 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, По чтению сейчас буду разбираться, а вот при изменении strBuffer на bytBuffer информацию больше не находит. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 14:00 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
забыл написать тк когда мы ищем байты то и искомые строки надо в байты перевести те strLineEnd strUserInfo и тд те все что ищем вот функция private sub StrToByt(byval strSource as string, byref bytDestination() as Byte) dim lngIndex as long ReDim bytDestination(len(strSource)-1) for lngIndex = 1 to len(strSource) bytDestination(lngIndex-1)=asc(mid(strSource, lngIndex, 1)) next end sub а это ее использование dim bytLineEnd() as Byte dim bytUserInfo() as byte StrToByt(vbcrlf, bytLineEnd) StrToByt("UserInfo", bytUserInfo) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 14:16 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, мдааааааа учиться мне еще и учиться. СПАСИБО Вам за помощь! ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 14:20 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menА где можно почитать про такие нюансы? Я что то в хелпе такого не нашел.Только в разных обсуждениях, запасясь поллитрой. Если без поллитры, то тем же профайлером можно выявлять аномально тормозные процедуры или инструкции и выяснять причины аномалий более предметно. По мере накопления статистики причины начнут классифицироваться и превращаться в правила... 1) Помнить о типах. 2) COM тормозит. Нужно по возможности выносить из циклов объектные вызовы. 3) В каких-то случаях быстрее ByVal, в каких-то — ByRef. 4) Строки тормозят. При малейшей возможности свалить все работы со строками на специализированные функции/компоненты. 5) Матан. Если часто (в цикле, например) вычисляется какая-то формула с несколькими параметрами, в 99 случаях из 100 из нее можно выделить часть-константу, которую можно посчитать до начала цикла. И куча более узких правил, которые не вспомнишь до тех пор, пока не увидишь их нарушения в коде. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 14:42 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
извините за оффтоп.... а так while(<>){if {m//){}} не пробовали еще? Я когда начал пробовать - мне понравилось. оно гигабайтами жрет, и не поперхнется. Бейсик - тоже очень хороший язык.... но логи - на перле бы? его же специально именно для этого и придумали )))). поначалу непривычно, а потом - быстро и четко. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 15:04 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерprivate sub StrToByt(byval strSource as string, byref bytDestination() as Byte) dim lngIndex as long ReDim bytDestination(len(strSource)-1) for lngIndex = 1 to len(strSource) bytDestination(lngIndex-1)=asc(mid(strSource, lngIndex, 1)) next end sub а это ее использование dim bytLineEnd() as Byte dim bytUserInfo() as byte StrToByt(vbcrlf, bytLineEnd) StrToByt("UserInfo", bytUserInfo) Прошу прощения за невежество. У Вас определение идет как SUB. Тогда ее вызов я так понимаю должен быть Код: vbnet 1. 2.
Но в этом случае возвращаемое в переменные bytLineEnd и bytUserInfo неопределено. те. MSGBOX возвращает ? Если это функции то их значение должно чему то присваиваться. тогда получается непонятно определение зачем в функцию передавать байтовые переменные bytLineEnd() и bytUserInfo() если им надо присваивать. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 15:25 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
call имя функции или процедуры писать не стоит тк это всего лишь лишнее слово и скобки лучше просто имя функции и ее параметры но без скобок в функцию передается массив байтов byref те передается по ссылке это значит что при выходе из него изменения внесенные в этот массив останутся можно посмотреть в отладчике это массив после присвоения там должны быть те же символы что и в исходной строке ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 16:06 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, Что то я делаю не так массив не передается из процедуры в bytLineEnd. поставлю преобразование в код, тем более оно разовое. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 16:21 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерcall имя функции или процедуры писать не стоит тк это всего лишь лишнее слово и скобки лучше просто имя функции и ее параметры но без скобок в функцию передается массив байтов byref те передается по ссылке это значит что при выходе из него изменения внесенные в этот массив останутся можно посмотреть в отладчике это массив после присвоения там должны быть те же символы что и в исходной строке Предидущее сообщение написал не прочтя ваше последнее сообщение ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 16:30 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 16:41 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Код: vbnet 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 16:44 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерединственно что нужно учесть это то что какой-то кусок у нас остался не проверенный LnEndSectionPos позиция последней найденной записи а кусок от LnEndSectionPos до BufferSize не исследован поэтому надо этот кусок поместить в начало буфера в диапазон [0, BufferSize - LnEndSectionPos] и читать следующий кусок записывая данные в диапазон [BufferSize - LnEndSectionPos, BufferSize] Правильно я понимаю что получается примерно такая вещь: Пусть Файл некий набор данных и мы его рубим кусками пусть по 10 МБ Код: plaintext 1.
тогда мы читаем некое количество байт до первого вхождения в диапазон UserInfo. После этого мы по сути осуществляем сдвиг диапазона. Правильно? Код: plaintext 1.
А что происходит в случае если искомый фрагмент окажется на границе. (выделю его слешами). Не будет ли в этом случае потери данных? Код: plaintext 1.
и кстати а в чем задается буфер в байтах, Кб или Мб. То что я видел вроде в байтах. А ограничение кроме системных (в смысле больше 100Мб система не обрабатывает) есть какие? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 17:08 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, И еще не понял для чего в FileRead передовать размер буфера если можно изначально определить как Код: vbnet 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 17:22 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, Наверное понятнее будет так. В FileRead делаю. Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Далее перехожу в BufferParse. а там будет так. Код: vbnet 1. 2. 3.
а по окончании выгрузки фрагмента передавать BufPosition=LnEndSectionPos+1 и я так понимаю мне еще надо на EOF проверять. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 18:22 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
> Автор: Alex_men Открывай файл _ДО_ цикла обработки и закрывай _ПОСЛЕ_, а ты открываешь/закрываешь при чтении каждой порции Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 18:27 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
можно не передавать размер буфера в функцию я просто предложил так чтобы можно было легко менять размер буфера а значит можно будет при желании определить зависимость скорости работы от размера буфера буфер должен быть не меньше размера максимальной записи иначе придется читать с диска одни и те же данные несколько раз границы надо корректно обрабатывать пусть у на такой разрыв аааааааааUs erInfobbbbbbbbbbbbbbb соответственно мы не найдем посленей строки UserInfo при сканировании буфера поэтому все данные которые находятся в буфере в диапазоне [последняя найденная позиция, конец буфера] надо скопировать в диапазон [0, длина остатка=размер буфера - последняя найденная позиция] и прочитать данные из файла но уже не размером с размер буфера а размером [размер буфера - длина остатка] и записать их в диапазон [длина остатка, размер буфера] тк у нас размер буфера достаточный для того чтобы поместилась хотя бы одна запись целиком то при следующем сканировании мы найдем хотя бы одну запись UserInfo ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 18:41 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menпарсер, с AWK смотрю но по указанному алгоритму у меня ничего не находит, хотя и отрабатывает быстрою результат =0. А как файл кусками читать. или вот еще нашел можно проекцию создавать и работать с нейРеальный лог файл покажи. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 19:00 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерграницы надо корректно обрабатывать пусть у на такой разрыв аааааааааUs erInfobbbbbbbbbbbbbbb соответственно мы не найдем посленей строки UserInfo при сканировании буфера поэтому все данные которые находятся в буфере в диапазоне [последняя найденная позиция, конец буфера] надо скопировать в диапазон [0, длина остатка=размер буфера - последняя найденная позиция] и прочитать данные из файла но уже не размером с размер буфера а размером [размер буфера - длина остатка] и записать их в диапазон [длина остатка, размер буфера] Мне кажется я понял о чем вы говорите. Поправьте меня если я не прав, но мне кажется при моем алгоритме такая ситуация исключена. Сейчас объясню почему. У меня есть диапазон имеющий четкие границы : Начало диапазона INCOMINGTIME и конец диапазона OUTGOINGTIME. и где то внутри сидит в произвольном месте параметр USERINFO. USERINFO является критерием поиска. и когда я его нахожу получаю метку на первый символ USERINFO.Тут пока никаких противоречий вроде нет. Так вот по обнаружении метки я не продолжаю читать дальше по файлу. Я выделяю диапазон в котором находится обнаруженный USERINFO. Диапазон от vbCrLf перед меткой начала диапазона INCOMINGTIME до vbCrLf расположенного за меткой конца диапазона OUTGOINGTIME. И весь этот диапазон сбрасываю в файл результата, а в BUFFERPOSITION передаю позицию vbCrLf расположенного за меткой конца диапазона OUTGOINGTIME. И затем читаю следующий диапазон. Боюсь тут даже возможны вариаты перекрытия диапазонов (хотя вроде и без двойного прохода по одним и тем же местам. Я так понимаю что при таком подходе пропусков быть не должно. парсертк у нас размер буфера достаточный для того чтобы поместилась хотя бы одна запись целиком то при следующем сканировании мы найдем хотя бы одну запись UserInfo т.е. я правильно понимаю что если у меня клитерий поиска имеет размер 160 символов, то размер буфера должен быть не меньше 160 символов? А вот как быть если у меня в буфер считалось вот такая пограничная ситуация: "ввввввввввааааааааааааааассссссссссссUser" вторая часть попадетв следующий фрагмент файла? "Info ыыыыыыыыыыыыыыыыывввввввввввввввввв" ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 23:10 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, а понял по достижении конца фрагмента надо с помощью INSTRREV откатится к последней завершенной секции лога OUTGOINGTIME и с нее начинать чтение следующего фрагмента. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 23:14 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
я не могу определить правильно или нет тк не очень понял надо пытаться писать и смотреть что получится но смысл простой мы должны файл прочитать по кускам ровно один раз за один проход причем буфер в памяти у нас всегда один и тот же. это самый лучший способ но кусочки для чтения будут не равными тк может часть текста остаться от предыдущего поиска кстати White Owl предложил помощь можно попросить чтобы он написал правильное выражение для поиска это будет помощь тк свою функцию будет с чем сверить ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 23:33 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
White Owl, Прошу прощения Лог у меня на работе. могу только повторить то что уже писал тут. могу только повторить с комментариями. Структура приведенная ниже соответствует выполнению одного действия пользователем. И всегда одинаково начинается с >IncomingTime и заканчивается всегда >OutgoingTime. Набор остальных секций внутри фрагмента может отличаться. Соответственно весь файл лога состоит из набора таких фрагментов. Размер файла варьируется от 200 кб до 200-250 МБ (и имеет тенденцию к росту). Может быть это поможет.Если нет, то до понедельника. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2011, 23:57 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
правильно я понял что между IncomingTime OutgoingTime может не быть UserInfo и таких случаев много? иначе можно просто искать по IncomingTime OutgoingTime ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 00:13 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Правильно при некоторых системных событиях UserInfo может отсутствовать, а например если пользователь зашел в систему , но еще не авторизовался (как раз вводит логин пароль) то UserInfo может быть пустой секцией что соответствует понятию Guest. А мне нужно отобрать данные по содержимому этой секции т.е по Иванову Ивану Ивановичу при этом начисто игнорируя Сидорова Федора Кузьмича ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 00:27 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
а зачем тогда IncomingTime искать ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 00:30 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
те нашли UserInfo нашли начало строки перед ним нашли конец строки за ним нашли конец строки еще один получили нужный блок ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 00:34 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерте нашли UserInfo нашли начало строки перед ним нашли конец строки за ним нашли конец строки еще один получили нужный блок не совсем. т.к. отчет готовится по конкретному Иванову или по Петрову или по сидорову (т.е. по одному пользователю) то Userinfo я не смотрю в принципе. Я ищу Иванова. Как только я нашел Иванова ище начало строки перед ближайшим предидущим IncomingTime (начало нужного фрагмента) начало строки перед ближайшим последующим IncomingTime (Конец нужного фрагмента). Получил нужный блок. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 00:42 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
кажется понял но тогда White Owl никак не поможет он же не знает всех ивановых петровых и тд опять же возникает вопрос из одного огромного файла лога берется только иванов? и что для каждого пользователя свой лог? если это не так те один лог содержит много пользователей то логично делать наоборот те найти userinfo посмотреть для кого если надо делать для него отчет то сделать иначе пропустить ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 00:55 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
да еще вопрос не по теме а почему выбран бейсик для задачи а не .net ведь там очень много возможностей и проблем гораздо мешьше Visual Studio 6 мне кажется сегодня и найти не просто ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 01:00 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсеркажется понял но тогда White Owl никак не поможет он же не знает всех ивановых петровых и тд опять же возникает вопрос из одного огромного файла лога берется только иванов? и что для каждого пользователя свой лог? если это не так те один лог содержит много пользователей то логично делать наоборот те найти userinfo посмотреть для кого если надо делать для него отчет то сделать иначе пропустить Ну Иванова я просто в форме ввожу. И действительно мне нужно получить информацию что сделал Иванов за указанный в запросе период. Лог для всех пользователей один. Если честно не понимаю почему логичней искать UserInfo? Получается больше операций в программе. В Вашем варианте 1) найти USERINFO 2) проверить его содержимое 3) найти начало фрагмента лога 4) найти конец фрагмента лога. Скажем так в USERINFO содержится информация которая мне позволит точно идентифицировать пользователя, помимо ФИО еще ID в системе. Таким образом мне как раз достаточно посмотреть сочитание Иванов +ID. С VB все просто. когда то давно контора купила VisualStudio 6. Сотрудник под которого покупалось, считал что ему и АКСеса хватит. Потом он Ушел и мне в наследство досталась куча программ и базок разного калибра на Аксесе. Я их поддерживал тихонечка осваивая VBA. А последнее время пошли задачки под которые Аксесс явно маловат да и коды открытыми держать нехотелосьбы. Вот я и перешел на VB6. Говорить что мне нужна более современная среда говорю, но в ответ предлагают 2010 Аксес ну или что там есть по лицензии. :) а могли и в опенофис послать :) А пока начальству капаю узнаю много интересного и полезного. А ставить пиратку не могу слишком велика вероятность проверки. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 01:18 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
А если поставить SQL Express? Я не думаю. что объемы ваших данных превысят ограничения бесплатной версии. Раз вы все равно вынуждены (и способны) осваивать новые срЕды - то почему бы сразу не заняться импортом и анализом с точки зрения СУБД? Тем более, что с акцессом вы знакомы. А юзвери будут спокойно получать из базы любые выборки стандартными средствами (например, через ADODB) себе в любимый WORD... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 03:57 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
AndreTM, Да я и с SQL малость знаком :) Только работа с базой данных повышает время анализа как минимум на время импорта данных из файлов. Старый вариант программы примерно так и работал. Только чтобы не тратить время на импорт я подлинковал текстовый файл с именем tmp.log в виде таблицы. и каждый новый файл подкладывал на место проанализированного. Но запрос с условием Код: vbnet 1.
отрабатывает примерно с той же скоростью что и построчное чтение из файла. А вот в гибкости программа теряет. т.к. Надо при смене место положения программы на машине либо перелинковывать файл либо располагать программу по тем же путям. Ну и самый главный минус время. Сейчас с помощью ребят анализ идет 1-2 секунды. Осталось только проход по большим файлам оптимизировать ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 18:39 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_menСтруктура приведенная ниже соответствует выполнению одного действия пользователем. И всегда одинаково начинается с >IncomingTime и заканчивается всегда >OutgoingTime.Между OutgoingTime и IncomingTime могут быть строки? Может информация о двух юзерах быть перемешанной? Тот awk скрипт который я публиковал идеально отрабатывает на примере. Если он не работает на реальном файле, значит реальный файл отличается от примера. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 18:48 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
White OwlAlex_menСтруктура приведенная ниже соответствует выполнению одного действия пользователем. И всегда одинаково начинается с >IncomingTime и заканчивается всегда >OutgoingTime.Между OutgoingTime и IncomingTime могут быть строки? Да. После строки содержащей OutgoingTime идет строка с цифровым значением даты и времени. Потом идет пустая строка между строками. именно поэтому я для определения конца фрагмента использую начало строки содержащей IncomingTime следующей секции White OwlМожет информация о двух юзерах быть перемешанной? нет программа в лог пишет законченные фрагменты. Так же как и разрыв в логе возможен только при каком то аварийном завершении работы системы в целом. например при отключении питания сервера. White OwlТот awk скрипт который я публиковал идеально отрабатывает на примере. Если он не работает на реальном файле, значит реальный файл отличается от примера. Возможно я что то не так сделал. Просто сейчас я посчитал что параллельное изучение AWK и написание программы замедлит достижение результата. AWK я скачал вместе с документацией. для последующего изучения. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2011, 22:05 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
не по основной теме Access 1 Access ведь позволяет создавать mde файлы а в них в нет исходного кода 2 можно создать связанную таблицу не только из родного mdb но и подключить базу sql server разница только в параметрах подключения 3 Более удобного и быстрого способа построения интерфейса программы чем в Access я не встречал хотя может они и есть 4 конечно для нашей задачи любая бд не помощник .net 1 Visual Studio Express SqlServer Express вроде бы бесплатные и любой может скачать их с микрософта 2 Имеем новую платформу с очень большими возможностями 3 Изучать ее более перспективно чем VB 4 Вообщем при возможности этим стоит заняться 5 наверное для нашей задачи .net не помощник по поводу парсера сегодня у меня вряд ли получится посмотреть что-то но завтра хочу еще кое-что посмотреть на текущий момент я сделал следующие открытия 1 я предложил strBuffer as String заменить на bytBuffer() as Byte для экономии памяти но оказалось 2 память конечно сэкономилась и можно в два раза больший буфер выделить 3 InStrB медленней в три раза чем InStr 4 InStrRevB отсутствует парсинг заружая файл по частям 1 я пока еще не все посмотрел 2 бейсик цикл For lngIndex = 1 to 1 000 000 000 делает медленно а это как раз гигабайт 3 читая по кускам мы увеличиваем количество вызовов функции InStr те если у нас есть 10 Мб а в них только две записи удовлетворяющих критерию поиска и размер каждой записи 1МБ если все 10МБ загружены в память то за 2 вызова InStr (только две записи удовлетворяют поиску) мы отсканируем весь файл 10Мб а теперь посмотрим что будет если будем читать файл кусками по 1Мб прочитали 1 Мб вызвали InStr и так десять раз результат поиска тот же но InStr вызывалась в пять раз больше раз 4 у меня подозрение что увеличение количества вызовов функции InStr может существенно замедлить программу как раз это я и собираюсь проверить 5 именно поэтому когда мы ищем строку мы ищем самую фильтрующую подстроку в первую очередь те первой надо искать строку иванов иван иванович и лучше поискать потом назад и вперед от найденной позиции но если таки фамилий целый список тогда получается что лучше искать по UserInfo если записей с UserInfo существенно меньше чем всех записей а если UserInfo почти в каждой записи тогда надо просто искать IncomingTime OutgoingTime формат файла лога 1 признаюсь до сих пор не я уверен что правильно понимаю формат файла лога 2 мне это не важно а вот Owl для написания правильного запроса необходимо 3 когда я создал свой тестовый файл и прогнал gawk который дал Owl у меня все нашлось и быстро 4 я gawk синтаксис не смотрел пока не было времени потому в gawl я не советчик 5 предлагаю написать здесь четкий алгоритм того что надо найти и куда этого в итоге будет выгружено 6 чтобы любой мог прочитав этот алгоритм мог сразу написать прогу парсера и она оказалось верной 7 понятно какие-то специфические действия не нужны пример алгоритма 1 из файла source.txt размером 1200 МБ извлекаются записи и помещаются в файл destination.txt 2 размер каждой записи не превышает 10Мб (а может он вообще не ограничен) 3 запись удовлетворяющая критерию поиска находится так 4 обозначения <символ новой строки> <cr> <любое количество любых символов> <*> 5 начало записи это строка <cr><*>IncomingTime<*><cr> 6 конец записи это строка <cr><*>OngoingTime<*><cr><*><cr> (после строки OngoingTime идет еще одна строка) 7 запись содержит <cr><*>UserInfo<*><cr><*>Иванов<*>Иван<*>Иванович<*><cr> вот так я понимаю алгоримт поиска который нужен ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2011, 16:04 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерне по основной теме Access 1 Access ведь позволяет создавать mde файлы а в них в нет исходного кода 2 можно создать связанную таблицу не только из родного mdb но и подключить базу sql server разница только в параметрах подключения 3 Более удобного и быстрого способа построения интерфейса программы чем в Access я не встречал хотя может они и есть 4 конечно для нашей задачи любая бд не помощник В mde код есть, только он не доступен для редактирования. А посмотреть его очень даже можно. и Работает mde быстрее , чем Mdb. А так собственно никакой разницы. Подключение аксеса к базам это я знаю. У меня есть несколько прогрммок, база для которых не на mdb а на sql вертится (я даже как то к лотусу ради эксперимента цеплялся). Ну по построению интерфейса Аксес конечно легче. НО его же не выгрузишь потом в VB если надо сделать EXE c нормальным дистрибутивом. с п.4 согласен на 100% т.к. это привносит изрядное количество лишних операций над данными. парсер.net 1 Visual Studio Express SqlServer Express вроде бы бесплатные и любой может скачать их с микрософта 2 Имеем новую платформу с очень большими возможностями 3 Изучать ее более перспективно чем VB 4 Вообщем при возможности этим стоит заняться 5 наверное для нашей задачи .net не помощник Хмм а тут я тормознул. Нет про SqlServer Express я знаю, а вот подумать что можно поискать у мелкософта Visual Studio Express SqlServer Express чтото не догадался парсерпо поводу парсера на текущий момент я сделал следующие открытия 1 я предложил strBuffer as String заменить на bytBuffer() as Byte для экономии памяти но оказалось 2 память конечно сэкономилась и можно в два раза больший буфер выделить 3 InStrB медленней в три раза чем InStr 4 InStrRevB отсутствует пункт 3 не заметил т.к в обоих случаях идет выполнение в течении 1 сек. Оставил все на Instr чтобы не связываться дополнительными преобразованиями. пункт 4 еще в пятницу в хелпе прочитал :) и еще наткнулся на то,что при таком анализе перед записью в файл результата требуется обратное преобразование информации. парсерпарсинг заружая файл по частям 1 я пока еще не все посмотрел 2 бейсик цикл For lngIndex = 1 to 1 000 000 000 делает медленно а это как раз гигабайт 3 читая по кускам мы увеличиваем количество вызовов функции InStr те если у нас есть 10 Мб а в них только две записи удовлетворяющих критерию поиска и размер каждой записи 1МБ если все 10МБ загружены в память то за 2 вызова InStr (только две записи удовлетворяют поиску) мы отсканируем весь файл 10Мб а теперь посмотрим что будет если будем читать файл кусками по 1Мб прочитали 1 Мб вызвали InStr и так десять раз результат поиска тот же но InStr вызывалась в пять раз больше раз 4 у меня подозрение что увеличение количества вызовов функции InStr может существенно замедлить программу как раз это я и собираюсь проверить 5 именно поэтому когда мы ищем строку мы ищем самую фильтрующую подстроку в первую очередь те первой надо искать строку иванов иван иванович и лучше поискать потом назад и вперед от найденной позиции но если таки фамилий целый список тогда получается что лучше искать по UserInfo если записей с UserInfo существенно меньше чем всех записей а если UserInfo почти в каждой записи тогда надо просто искать IncomingTime OutgoingTime Я тоже этот вариант посмотрел. Тут у меня несколько вопросов появилось. 1)Если файл меньшего объема чем зарезервированная область в буфере. не будет ли тут программа спотыкаться? Или например надо просмотренную информацию в буфере сбросить перед чтением следующего фрагмента файла? 2)Как идет адресаций при просмотре файла фрагментами (я имею ввиду переменную LngBufferPosition)? она сквозная для всего файла или в каждом фрагменте , помещенном в StrBuffer, идет с 1 позиции? 3) Пока не понял почему, но при малом значении размера буфера программа теряет связь с файлом результата. т.е. Первые несколько проходов по StrBuffer и запись результатов нормально, а затем File Not Found. При увеличении размера буфера это пропадает, но я так полагаю исключительно из-за того что уменьшается количество проходов. по пункту 5. Отчет делается по конкретному Иванову Ивану Ивановичу. Не по списку. Т.к. надо по каждому Иванову или Сидорову сделать свой файл с результатами. парсерформат файла лога 1 признаюсь до сих пор не я уверен что правильно понимаю формат файла лога 2 мне это не важно а вот Owl для написания правильного запроса необходимо 3 когда я создал свой тестовый файл и прогнал gawk который дал Owl у меня все нашлось и быстро 4 я gawk синтаксис не смотрел пока не было времени потому в gawl я не советчик 5 предлагаю написать здесь четкий алгоритм того что надо найти и куда этого в итоге будет выгружено 6 чтобы любой мог прочитав этот алгоритм мог сразу написать прогу парсера и она оказалось верной 7 понятно какие-то специфические действия не нужны пример алгоритма 1 из файла source.txt размером 1200 МБ извлекаются записи и помещаются в файл destination.txt 2 размер каждой записи не превышает 10Мб (а может он вообще не ограничен) 3 запись удовлетворяющая критерию поиска находится так 4 обозначения <символ новой строки> <cr> <любое количество любых символов> <*> 5 начало записи это строка <cr><*>IncomingTime<*><cr> 6 конец записи это строка <cr><*>OngoingTime<*><cr><*><cr> (после строки OngoingTime идет еще одна строка) 7 запись содержит <cr><*>UserInfo<*><cr><*>Иванов<*>Иван<*>Иванович<*><cr> вот так я понимаю алгоримт поиска который нужен по пункту 2 размер записи плавает. И зависит от степени Журнализации лога выставленной на сервере. Скажем так при нынешней степени размер дневного лога составляет всего 150-300 Мб, а при полной журнализации 1,2Гб-2Гб. При сохранении тойже структуры. В остальном возражений по алгоритму нет. Собственно все это я с Вашей помощью уже сделал, Осталось только с большими файлами разобраться до конца. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 11:52 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
где-то по текстуПрошу прощения а Вы код не вредакторе пишите? Это какой-то отдельный редактор ? Просто на studio 10 в том редакторе очень комфортно программировать из-за многочисленных подсказок и меток от-до. Думаю, может есть отдельный редактор и компилятор? Заранее спасибо работал с немаленькой базой, своей тип Random. Примерно 8 таблиц таких связывал. Работает быстро, НО было время испробовать adodb и dao, та работает чучуть медленней, но зато в коде можно накосить из-за многострочной программы. И не помню какая из adodb или dao для меня не понравилась, поскольку простая функция там работала для меня непонятно. Перешел на базу данных. Что касается кнопки "Стоп", то нажимая на "Стоп" изменяем флаг переменной, а в цикле проверяем эту переменную. С DoEventами также можно запутаться. Против повторного запуска ненужного процесса используются флаги. На работе Dim переменная(максимальное количество строк) as string * на количество - одно, вдома - это число больше в несколько раз. В диспетчере видно как растет оперативка. Также может непредвиденно ругнуться. С типом вариант - вопше медляк/тужняк. Разборка строк осуществлялась замером Len(), отрезанием Mid, left, right (не пробовал разницы в скорости между mid и mid$, аналогично left$...), instr() и instrrev() Работая с разборкой строки большего объема на <html> теги, xml и еще одной системы (которая теги описывает квадратными скобками) сообщаю, что по сравнению с встроенными функциями других разработчиков (ну хотя-бы adobe плеер) аналогичных действий - эти процессы выполняются в десяток раз быстрей чем на VB ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 15:51 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Андрей159 где-то по текстуПрошу прощения а Вы код не вредакторе пишите? Это какой-то отдельный редактор ? Просто на studio 10 в том редакторе очень комфортно программировать из-за многочисленных подсказок и меток от-до. Думаю, может есть отдельный редактор и компилятор? Заранее спасибо работал с немаленькой базой, своей тип Random. Примерно 8 таблиц таких связывал. Работает быстро, НО было время испробовать adodb и dao, та работает чучуть медленней, но зато в коде можно накосить из-за многострочной программы. И не помню какая из adodb или dao для меня не понравилась, поскольку простая функция там работала для меня непонятно. Перешел на базу данных. Что касается кнопки "Стоп", то нажимая на "Стоп" изменяем флаг переменной, а в цикле проверяем эту переменную. С DoEventами также можно запутаться. Против повторного запуска ненужного процесса используются флаги. На работе Dim переменная(максимальное количество строк) as string * на количество - одно, вдома - это число больше в несколько раз. В диспетчере видно как растет оперативка. Также может непредвиденно ругнуться. С типом вариант - вопше медляк/тужняк. Разборка строк осуществлялась замером Len(), отрезанием Mid, left, right (не пробовал разницы в скорости между mid и mid$, аналогично left$...), instr() и instrrev() Работая с разборкой строки большего объема на <html> теги, xml и еще одной системы (которая теги описывает квадратными скобками) сообщаю, что по сравнению с встроенными функциями других разработчиков (ну хотя-бы adobe плеер) аналогичных действий - эти процессы выполняются в десяток раз быстрей чем на VB Я конечно извиняюсь, но что то тут сумбур какойто. Вопервых в изложенной задаче любая БД это значительное уменьшение быстродействия. Во первых из-за того что как правило разом обрабатывается от 370 файлов и больше со средним размером 150-200 Мб. Это надо каждый импортировать (раз замедление), обработать (запрос на поиск по параметру + запрос на поиск фрагмента а то и 2 запроса), выгрузить результат, по окончании обработки одного файла убить всю инфу плюс для некоторых БД неплохо бы было сжать базу например при использовании Mdb надо обязательно. Иначе достигаем 4Гб и программа базка падает. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 16:21 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
ТС, вам нужен специализированный софт. который делает text search по файлам компа (с интеграцией системного кэша), что-то вроде google search и тп ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 16:26 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
кстати в полных версиях SQL-server есть Full-Text Search ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 16:27 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
а что с редактором 11750479 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 16:29 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
посмотрел производительность убедился в том что мы не можем в бейсике делать интенсивный цикл из InStr интересно было бы посмотреть как тот же код будет работать в С++ поэтому если "Иванов" это строка очень редкая во всем файле то будет все работать со скоростью чтения большого лог файла временем на запись в результирующий файл можно пренебречь тк "Иванов" это строка очень редкая размер самой записи тоже не большой но если Иванов есть в каждой записи то работать не будет тормозит бесконечно сделал алгоритм который по частям читает ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 22:28 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
см parser.zip ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 22:43 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
не получается приложить файл наверное это можно сделать только зарегистрированным пользователям ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2011, 22:47 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерпосмотрел производительность убедился в том что мы не можем в бейсике делать интенсивный цикл из InStr интересно было бы посмотреть как тот же код будет работать в С++Тот же код в С++ будет работать так-же меделенно. У тебя в программе (которая в 11753402 ) куча фигни и ненужных действий. парсерпоэтому если "Иванов" это строка очень редкая во всем файлеНикаких "если". Редкость Иванова никак не влияет на задачу. Упрощай: Что изначально нужно? Нужно разбить весь лог на куски. Начало одного куска и начало следующего обозначен строкой в которой есть подстрока ">IncomingTime". Если в куске есть подстрока "Иванов", то этот кусок надо запомнить, иначе проигнорировать. Итого один цикл и в нем два instr или три если текст "Иванов" может появится не только в UserInfo: Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Все, и не надо заниматься многочисленным сканированием во всех направлениях. Принцип KISS никто не отменял. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2011, 01:06 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторWhite Owl поэтому если "Иванов" это строка очень редкая во всем файле я не знаю насколько эта строка редкая но то что это предположение существенно ускорит прогу я уже писал выше допустим весь файл размером 1 Гбайт мы загрузили в оперативку и в этом огромном файле только одна строка Иванов тогда всего лишь два вызова InStr достаточно чтобы обнаружить эту одну строку первый чтобы найти а второй чтобы убедиться что больше нет а теперь посчитаем сколько раз мы вызовем InStr если будем читать файл построчно ответ очень много а значит очень затормозим прогу я сгенерил тестовый файл размером 100Мб и в каждой строке была строка UserInfo и искал так InStr(strBuffer, "UserInfo") и больше ничего не делал те цикл из одной команды так вот 10 000 строк находило за разумное время но 100 000 это уже много и мне кажется что виноват бейсик хотя естественно это надо проверить все таки это не машинный код ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2011, 02:15 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
сделал очередное открытие которое все объясняет выделил буфер байтов bytBuffer() as Byte размером 50 000 байт и просканировал его N раз замерил время выделил буфер байтов bytBuffer() as Byte размером 60 000 байт и просканировал его 5* N / 6 раз замерил время общий объем памяти при сканировании остался тот же обнаружил то о чем никогда бы не подумал при буфере 50 000 время меньше секунды при буфере 60 000 время больше 5 секунд это значит что надо пользоваться буфером 50 000 не больше вот только если наша запись больше 25 000 то получается что мы не можем пользоваться этим алгоритмом алгоритм который я пользовал требует чтобы буфер был по крайней мере в два раза больше размера записи интересно почему такая разница во времени наверное тоже бейсик виноват ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2011, 13:16 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсерсделал очередное открытие которое все объясняет выделил буфер байтов bytBuffer() as Byte размером 50 000 байт и просканировал его N раз замерил время выделил буфер байтов bytBuffer() as Byte размером 60 000 байт и просканировал его 5* N / 6 раз замерил время общий объем памяти при сканировании остался тот же обнаружил то о чем никогда бы не подумал при буфере 50 000 время меньше секунды при буфере 60 000 время больше 5 секунд это значит что надо пользоваться буфером 50 000 не больше вот только если наша запись больше 25 000 то получается что мы не можем пользоваться этим алгоритмом алгоритм который я пользовал требует чтобы буфер был по крайней мере в два раза больше размера записи интересно почему такая разница во времени наверное тоже бейсик виноват странно пользовался буфером 72231300 и 108346950 и там и там секунда ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2011, 13:30 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
я брал N такое чтобы N * 50 000 = 1 000 000 000 как продвигается парсинг файлов не пробовали той функцией что я предложил прогонять огромный файл? кстати перефомулировка одного из вопросов которые я уже спрашивал у нас есть большой файл лога 1Гбайт мы его обрабатываем и получаем результирующий новый файл размером каким? предположим этот файл в 100 раз меньше исходного тогда при таком простом фильтре как у нас мы должны получить скорость обработки приблизительно равную скорости чтения большого 1Гбайт файла лога ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2011, 14:49 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Бюджет на следующий год делаю. Добью вернусь с программой ... |
|||
:
Нравится:
Не нравится:
|
|||
13.12.2011, 16:39 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
вот новая версия предыдущего парсера работает быстро написал функции аналогичные InStr InStrB ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 15:36 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
посмотрел производительность работы диска на чтение при разных размерах буфера 1 readline FileSystemObject самая медленная 2 FileRead(lngFileHandle, lngBufferAddress, lngBufferLength) при размере &H1000 (4КБайт ) достаточно быстрая 3 FileRead(lngFileHandle, lngBufferAddress, lngBufferLength) при размере &H1000000 (16 Мбайт) быстрее предудыщей 4 FileRead(lngFileHandle, lngBufferAddress, lngBufferLength) при размере 10 * &H1000000 (160 Мбайт) быстрее из п2 в три раза получается что увеличение размера буфера увеличивает скорость чтения грубо говоря надо взять такой буфер который диск физически не успеет заполнить за 1 секунду те если диск читает 100 Мбайт/сек то надо брать буфер больше 100 Мбайт ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 18:26 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
я понимаю задачу так 1 есть несколько файлов логов 2 есть несколько человек о которых надо извлечь информацию из всех логов если это так то можно подправить текущий алгоритм следующим образом 1 передавать список файлов логов в функцию парсера и когда полностью прочитаем файл то не выходить из цикла а просто открыть и прочитать следующий файл понятно что формат логов должен быть один и тот же. это позволит не возиться с написанием батников которые по очереди запускают парсинг передавая каждый раз новое имя файла для парсинга 2 передавать список людей по которым хотим извлечь информацию и когда мы найдем запись с UserInfo просканировать эту запись N раз (количество человек в списке) и соответственно записывать результат в файл для конкретного человека те для каждого человека открываем и держим открым файл результата до конца обработки это нужно сделать тк это очень ускорит прогу получается что за одно сканирование всех исходных файлов мы получим результат сразу для всех людей если же для каждого человека отдельно запускать сканирование файла то для 10 человек получится что мы сканируем один и тот же файл 10 раз а для 100 человек 100 сканирований другими словами в идеале мы должны получить что скорость нашей обработки примерно равна скорости чтения всех файлов и скорости записи всех результирующих файлов тк у нас обрабока простая то ее время примерно нулевое ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 18:41 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсердопустим весь файл размером 1 Гбайт мы загрузили в оперативку и в этом огромном файле только одна строка Иванов тогда всего лишь два вызова InStr достаточно чтобы обнаружить эту одну строку первый чтобы найти а второй чтобы убедиться что больше нет а теперь посчитаем сколько раз мы вызовем InStr если будем читать файл построчно ответ очень много а значит очень затормозим прогуТы считаешь не правильно. Не важно сколько раз вызвать InStr, важно сколько букв будет проверено и предложенный тобой вариант поиска то во одном, то в другом направлении увеличивает нагрузку вдвое. В итоге - да, если "Иванов" встречается в каждом куске - ты будешь бегать по гигабайтному файлу дважды, сначала для поиска Иванова, потом в обратном направлении для поиска IncomingTime, в итоге ты обработаешь два гигабайта. Если Иванов встретится только один раз ты обработаешь гигабайт плюс размер одного куска. И только если Иванов вообще не встретится ты ограничишься одноразовым проходом по файлу. А если искать начало куска (вместо Иванова) и начинать скидывать строки в буфер - то не важно сколько Ивановых в файле. В любом случае проход по файлу будет только один. парсери мне кажется что виноват бейсик хотя естественно это надо проверить все таки это не машинный кодНакладные расходы на вызов команд в Бейсике традиционно одни из самых высоких среди всех ЯП и накладные расходы на множественные вызовы InStr в принципе тоже будут влиять, но по сравнению со скорость работы самого InStr это исчезающе мало. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 19:17 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
я согласен с тем что если у нас одна запись может занимать весь файл то данный алгорим не подходит но я об этом и писал уже не раз а исхожу из того что запись гораздо меньше всего файла поэтому то что я ищу назад не критично опять же согласен что это повторная работа но она небольшая на текущий момент я понял что 1 надо читать файл большими кусками 2 бейсик не тормозит 3 анализ текущего буфера можно делать любым алгоритмом 4 когда я знаю максимальный размер записи и она целиком помещается в буфер я использую текущий алгоритм 5 действительно можно просто сначала найти IncomingTime потом UserInfo и все просто это немного другой алгоритм. а я использую тот же алгоритм который был в самом начале в самом первом примере парсинга алгоритм IncomingTime, UserInfo тут проблема в том что мы должны найти UserInfo между IncomingTime а как? если я сначала отсканирую буфер по UserInfo я могу пропустить IncomingTime если я сначала отсканирую буфер по IncomingTime я могу пропустить UserInfo те сканировать надо сразу по двум строкам такой функции нет надо ее писать ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 20:26 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
кстати текущая реализация на тестовом примере работает быстро правда размер записи у меня в этом примере небольшой но в любом случае я увеличиваю количество сканирований не больше чем в два раза а время загрузки файла в память гораздо больше времени сканирования этого файла в памяти. сканированием в памяти можно вообще пренебречь. но опять же повторюсь это все работает то тех пор пока запись целиком в буфере ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 20:31 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Может вам это пригодится. Стырено отсюда , там закрыто для незарегистрированных пользователей. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 20:36 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсеря согласен с тем что если у нас одна запись может занимать весь файл то данный алгорим не подходит но я об этом и писал уже не раз а исхожу из того что запись гораздо меньше всего файла поэтому то что я ищу назад не критично опять же согласен что это повторная работа но она небольшаяВот в этом и есть твоя главная ошибка. Если Иванов встречается редко - то не критично. Но ты не знаешь насколько редок Иванов. Ты закладываешься на идеальное расположенние данных в потоке и получаешь плохую производительность если данные расположены не идеально. парсералгоритм IncomingTime, UserInfo тут проблема в том что мы должны найти UserInfo между IncomingTime а как? Вот тут: 11753792 я уже показал как это делается. Не смотри на ReadLine если они тебя смущают. Смотри на использование вспомогательной переменной. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 20:54 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсеря понимаю задачу так 1 есть несколько файлов логов 2 есть несколько человек о которых надо извлечь информацию из всех логов если это так то ОДИН ЧЕЛОВЕК ЗА ОДИН РАЗ. ПО ГРУППЕ ЛИЦ ИНФОРМАЦИЮ НЕ ИЩЕМ. И фрагмент содержащий UserInfo действительно меньше размера файла. Как правило МНОГО меньше соотношение примерно как десятки МБ (файл) к десяткам Кб(ФРАГМЕНТ). А вообще я вот в какой пограничной ситуации встрял в тупик. Обработать ситуацию когда сам фрагмент лога попадает на границу текста считанного в буфер. Причем если он попадает на границу вконце Фрагмента ФАЙЛА в буфере поймать можно и не сложно, то вот когда НАЧАЛО фрагмента лога в обном фрагменте буфера (ФРАГМЕНТ А) а все остальное во втором фрагменте (ФРАГМЕНТ Б) вызвало небольшие затруднения Фрагмент А Фрагмент Б Код: plaintext 1.
Новый вариант парсера сейчас посмотрю. Особенно мне интеренсно то что вы широко API используете. Есть где поучится и кое что в копилку знаний положить. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 21:06 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
White OwlНикаких "если". Редкость Иванова никак не влияет на задачу. Упрощай: Что изначально нужно? Нужно разбить весь лог на куски. Начало одного куска и начало следующего обозначен строкой в которой есть подстрока ">IncomingTime". Если в куске есть подстрока "Иванов", то этот кусок надо запомнить, иначе проигнорировать. Итого один цикл и в нем два instr или три если текст "Иванов" может появится не только в UserInfo: Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Все, и не надо заниматься многочисленным сканированием во всех направлениях. Принцип KISS никто не отменял. Выглядит на удивление просто. Завтра с утра опробую непременно. А что за принцип KISS??? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 21:13 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторWhite Owl 11753792 я только примерно понял что там написано еще раз вопрос IncomingTime IncomingTime UserInfo как нам понять что надо взять втрое IncomingTime тк оно ближе к UserInfo? в примере мы читаем построчно но это значит что конец строки уже кто-то за нас нашел те уже отсканировал этот кусок строки до символа конца строки а мы сканируем уже повторно получили два сканирования ничем не лучше ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 21:28 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторAlex_men пример не так просто запустить придется сначала его полностью посмотреть в общих чертах чтобы хотя бы параметры передать и понять имя функции запуска спрашивайте если что алгоритм такой размер записи Х размер буфера 2Х тогда если в результате сканирования мы нашли UserInfo во второй половине буфера те позиция >Х and <2х тогда заведомо начало записи лежит в буфере и мы его находим если нашли и конец записи в буфере продолжаем как обычно если не нашли конец записи в буфере то сдвигаем все данные в буфере так чтобы начало записи лежало в позиции 0 ноль и подгружаем новый кусок и ищем конец записи а он заведемо должен быть тк запись загружена с позиции 0 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 21:37 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторAlex_men 1 файлов логов один или несколько в которых храниться информация о конкретном человеке? 2 получается что есть кнопка на форме в которой выбираем человека и для этого человека извлекаем инфу но тогда если в следующий раз мы введем другого человека то опять будем все сканировать 3 так вот если в одном файле хранится информация о всех возможных человеках и список этих возможных человеков известен заранее то можно за один проход извлечь всю информацию сохранить и просто показывать при следующем запросе. конечно если логи меняются со временем и нужны самые свежие данные то это не пройдет ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2011, 21:49 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер11753792 я только примерно понял что там написаноНуууу.... читай еще раз. Там кода совсем не много. парсереще раз вопрос IncomingTime IncomingTime UserInfo как нам понять что надо взять втрое IncomingTime тк оно ближе к UserInfo?А мне это не нужно, я набиваю буфер строками от одного IncomingTime, до другого IncomingTime. Если во время чтения нашел нужный UserInfo то хорошо, не нашел - тоже хорошо. В буфере не бывает двух IncomingTime, поэтому вопрос "который из них ближе" не имеет смысла. парсерв примере мы читаем построчно но это значит что конец строки уже кто-то за нас нашел те уже отсканировал этот кусок строки до символа конца строки а мы сканируем уже повторно получили два сканирования ничем не лучше В принципе - да. Загрузить весь файл в память и работать с ним как с один длинным текстом в теории будет быстрее чем если читать файл построчно. Но только до определенного предела - чем больше файл, тем больше нужда в свопе. Поэтому на маленьких файлах (до четверти ОЗУ) действительно эффективнее грузить все в память разом и потом разбирать. Потом, примерно до размера в две трети ОЗУ, эффективность обоих методов почти одинакова. А когда файл выходит за размеры физического ОЗУ то грузить весь файл в память категорически противопоказано - будут свопы. И еще не забывай о фоновых задачах - они тоже требуют памяти... А буферизация вообще-то делается всегда. Операция чтения файла всегда делает буферизацию внутри собственных кэшей, которые рассчитываются на основе возможностей железа. Сразу скажу что в Бейсике у тебя нету доступа до этих буферов. Ты тут недавно занимался угадайкой с размером собственных буферов ( 11755841 ), вот эти найденые числа как раз и зависят от тех самых внутренних буферов. Считаешь отношение размер_твоего_буфера / размер_внутреннего_буфера_команды_чтения, чем ближе это отношение к целому числу тем общая скорость работы выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 01:07 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторА мне это не нужно, я набиваю буфер строками от одного IncomingTime, до другого IncomingTime. Если во время чтения нашел нужный UserInfo то хорошо, не нашел - тоже хорошо. В буфере не бывает двух IncomingTime вот теперь понятно только тогда мне это не очень нравиться тк получается если нашли запись без UserInfo то получается зря делали работу по набиванию буфера я думаю для этого алгоритма быстрее будет прочитать в буфер кусок файла просканировать буфер не набивать результирующий буфер а просто запомнить позицию в сканируемом буфере где нашли IncomingTime а сканирование будет быстрее если двигать позицию всегда на 1 байт вперед и смотреть не находится ли в текущей позиции либо IncomingTime либо UserInfo так получится что мы делаем одно сканирование но сравниваем с двумя строками если мы хотим еще и начало строки поймать то придется и ее добавить те будет три строки для сравнения вот только это все надо написать и измерить время выполнения вариант с использованием именно getline FileSystemObject я вообще не рассматриваю тк он очень медленно читает файл читать надо другой функцией почему-то цикл getline FileSystemObject читал со скоростью 4МБайт/с и быстрее читать не хотел ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 02:06 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсералгоритм такой размер записи Х размер буфера 2Х тогда если в результате сканирования мы нашли UserInfo во второй половине буфера те позиция >Х and <2х тогда заведомо начало записи лежит в буфере и мы его находим если нашли и конец записи в буфере продолжаем как обычно если не нашли конец записи в буфере то сдвигаем все данные в буфере так чтобы начало записи лежало в позиции 0 ноль и подгружаем новый кусок и ищем конец записи а он заведемо должен быть тк запись загружена с позиции 0 Размер искомого фрагмента лога от IncomingTime до OutgoingTime не фиксирован. Он может быть разным. Поэтому возможен вариант когда прочитали первый фрагмент файла от 0 до 2x и не нашли там UserInfo. Прочитали второй фрагмент нашли там UserInfoа вот IncomingTime от этого UserInfo остался в первой части. Тогда нужно либо переменную strFound постоянно держать в памяти (если действовать как White Owl накоплением) либо я так думаю делать так держать размер буфера побольше, чтобу там умещаляся десяток фрагментов. Тогда при первом сканировании если мы не нашли UserInfo откатываться к ближайшему OutgoingTime. В этом случае следующий фрагмент файла будет начинаться целым, еще не отсканированным фрагментом лога от IncomingTime до OutgoingTime. парсер1 файлов логов один или несколько в которых храниться информация о конкретном человеке? 2 получается что есть кнопка на форме в которой выбираем человека и для этого человека извлекаем инфу но тогда если в следующий раз мы введем другого человека то опять будем все сканировать 3 так вот если в одном файле хранится информация о всех возможных человеках и список этих возможных человеков известен заранее то можно за один проход извлечь всю информацию сохранить и просто показывать при следующем запросе. конечно если логи меняются со временем и нужны самые свежие данные то это не пройдет 1)Файлов логов много. Каждый день формируется свой файл лога, а информацию меньше чем за полгода не запрашивают. Итого за раз обрабатывается 180 файлов и больше, до 5 лет значится 1800-1900 файлов. Поэтому меня быстродействие та и волнует. Сейчас проверю насчет скорости обработки при росте файла (то что написал White Owl ) если действительно на больших файлах скорости окажутся сопоставимы сделаю обработку до 100 Мб через буфер остальное чтением. Но тут дело такое секундомер нужен :) 2 и 3 ) В файле за один день информации по Иванову может и не быть. Например он в отпуске с 5 по 15 был. я этого не знаю зато там есть Сидоров, Петров и Дятлов, так что размер файла все равно большой. Количество таких Ивановый порядка 1000 в системе и это как говорится не предел. Так что парсить ежедневно и раскладывать информацию отдельно по каждому дело абсолютно лишнее, да и место это опять же скушает даже будучи хорошенько заархивировано. плюс каждый день новый лог добавляется, так что по запросу все равно надо делать дополнительную обработку, а нет ли там Иванова. В общем бюджет сделан секндомер на столе пошел разбирать логи. Кстати я так по опытам понял что чем больше фрагмент в буфере тем: 1) выше скорость сканирования 2) Меньше возможностей возникновения пограничных ситуаций и проще их обходить. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 08:58 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторРазмер искомого фрагмента лога от IncomingTime до OutgoingTime не фиксирован. Он может быть разным. надо просто чтобы он не превышал какой-то определенной величины если будет в файле запись больше этой величины то прога либо выдаст ошибку либо молча пропустит этот кусок в зависимости от входного параметра авторПоэтому возможен вариант когда прочитали первый фрагмент файла от 0 до 2x и не нашли там UserInfo возможен но я сдвигаю часть буфера от [Х, 2Х] в позицию [0, Х] и подгружаю новый кусок а позицию [Х, 2Х] и теперь он найдется если он там был у меня максимальная скорость чтения (только чтения) файла с диска достигалась при буфере 200МБайт авторФайлов логов много. Каждый день формируется свой файл лога, а информацию меньше чем за полгода не запрашивают. Итого за раз обрабатывается 180 файлов и больше, до 5 лет значится 1800-1900 файлов значит надо сделать то что я предложил в п1 автор1 передавать список файлов логов в функцию парсера и когда полностью прочитаем файл то не выходить из цикла а просто открыть и прочитать следующий файл понятно что формат логов должен быть один и тот же. это позволит не возиться с написанием батников которые по очереди запускают парсинг передавая каждый раз новое имя файла для парсинга кроме того это позволит программно написать создание списка файлов для обработки раз файлов так много значит есть критерий по которому они выбираются для конкретного запроса ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 12:19 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Критерий очень простой формат имени файла ddmmyyyy.log. У меня кстати на машине P4 2.6 1Гб. Буфер больше 80 метров не уживается пишет OUT OF MEMORY. Далее при поточной обработке файлов через несколько итераций получаю BED FILE NAME OR NUMBER при записи в файл результата Код: vbnet 1.
. я уже и явно номера задал не пойму что делать, не будешь же каждый раз открывать файл перед записью и закрывать после записи. может я что не так делаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 12:47 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, Обошел ошибку открывая файл для записи через FSO. Итого по первым тестам 200Мб файл разбор 6 сек. набор файлов в 1ГБ минута. Файлы от 400 кб до 185 мб. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 13:17 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
200Мб файл разбор 6 с это быстро ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 13:59 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
> Автор: парсер > 200Мб файл разбор 6 с это быстро Это вопрос или утверждение? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 14:22 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Игорь Горбонос, Мне тоже интересно. уменьшени с 8 минут до6 секунд это быстро по моим ощущениям. Это отчет в течении часа на любой машине в офисе,а не полутора двух суток на очень хорошей рабочей станции. Пойду теперь смотреть , то что ребята предлагали. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 15:22 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Вместо того, чтобы каждый раз лопатить одни и те же файлы для разных фамилий, не рациональнее ли пройтись один раз по каждому файлу и создать индексную таблицу1 о смещениях для каждой фамилии. Поля таблицы1: FileName – DataDate – UserName - StartOffset – EndOffset где StartOffset – смещение от начала файла до стартового тэга (начало записи), а EndOffset – смещение от начала файла до завершающего тэга (конец записи) Если файлы данных могут модифицироваться, то хранить отдельную таблицу2 с именами файлов и их DateTimeStamp - ми. В случае, когда дата-время сохранения файла не совпадет с DateTimeStamp, то проиндексировать файл снова и обновить таблицу2.. Поля таблицы2: FileName - DataTimeStamp Тогда любой отчет будет заключаться в открытии файла данных, копировании в буфер фрагмента от начала до конца записи в соответствии с индексной таблицей1 и обработке буфера. Если таблицу сохранить в базе данных, то перед обработкой сначала с помощью SQL-запроса отфильтровать фамилию(и), а затем считать все записи по offset-ам из индексной таблицы и отпарсить. Если длина записи больше, чем позволяет "железо", то воспользоваться советом Antonariy Класс для работы с файлом, проецируемым в память . При этом операционка сама будет оптимально лопатить файл хоть в 2ГБ, с буферизацией, подстроенной под конкретное железо и открытые процессы. Про проецируемые в память файлы хорошо описано у Джеффри Рихтера . Насколько я понял, для автора класса это и было первоисточником. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 18:04 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
самое геморойное это выверять результаты :( ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 18:11 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
ZVI, я конечно не много еще знаю но по моему ваш совет а) по временным затратам сопоставим :) Возможно зная смещения информацию из файла можно отобрать быстрее. Но тут еще добавит свою капельку и работа запросов помимо того что все равно надо читать файл и осуществлять позиционирование по нему. А в случае больших файлов и чтение по частям. Не вижу преимуществ, разве что использование проекции в память что то даст. По моему тут как раз тот самый KISS о котором говорилось выше. б) требует постоянной обработки новых файлов чтобы держать базу со смещениями в актуальном состоянии. Или же перед составлением отчета надо пройтись по всем файлам которые не были обработаны со времени предидущего отчета. Дополнить табличку смещений и потом делать отчет. Проекция в память у меня стоит в завтрашнем плане изучения. Это интересная тема. Упоминания я находил в темах но конкретных примеров не было, а за источник информации отдельное СПАСИБО. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 18:28 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
а) Поиск в большом файле с самого начала или считывание фрагмента сразу с нужного offset-а - это 2 большие разницы по времени. А считывание одного и того же большого файла каждый очередной раз, это уже многократное увеличение времени обработки. б) Да, достаточно пройтись только по необработанным файлам, при необходимости можно вообще зарядить обработку на ночь, если работа позволяет. Проецируемые в память файлы в даном случае потребуются только, если размер одной записи слишком большой ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 18:49 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
ZVIкаждый очередной раз Имелось в виду для отчете по очередной фамилии. А с индексной таблицей будет достаточного одного прохода по каждой записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2011, 18:52 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Черт подери эту поддержку вместе с разработчиками. Вы были правы у них таки есть ситуации при которых идет переплетенние двух блоков информации по двум разным клиентам. Причем программа разбора логов разработчиков эти фрагменты вообще игнорит. Есть возможность еще отбирать фрагмет по sessionID но это усложнит все по самое немогу. Прийдется видимо ускорить изучение вопроса проекции файлов ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2011, 13:05 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
автору них таки есть ситуации при которых идет переплетенние двух блоков информации по двум разным клиентам не очень понял что это значит но если можно определить это перекрытие тогда может можно и извлечь из этого перекрытия только то что нужно как правило если мы можем извлечь информацию вручную или глазами то и прогу реализующую излечение тоже можно написать все-таки это лог файл а не изображение например авторПрийдется видимо ускорить изучение вопроса проекции файлов не понимаю как это может помочь я думаю вообще проекция файла в память для нашего случая не нужна вот случаи которые приходят в голову когда она действительно может пригодиться 1 загрузка исполняемого файла помимо загрузки кода загрузчик должен настроить таблицу импорта функций а это связано с записью в exe файл тк писать в exe файл нельзя то без проекции в файл пришлось бы выделить буфер записать туда таблицу импорта объяснить системе что таблица импорта теперь находится по новому адресу имея проекцию в файл система автоматически при записи в память выделит место в своп-файле и запишет туда данные при этом адрес данных в памяти вообще не измениться те ключевым здесь является постоянство адреса в памяти 2 мы хотим выделить память которая будет доступна сразу нескольким процессам ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2011, 14:53 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Я уже набросал алгоритм. сейчас делаю. Тут по TraceID четко выбирается нужные секции. Границы думаю определять от vbCrLf начала строки содержащей нужный TraceID до [yyyy.mm.dd_ (это можно из названия файла брать). Вот дальше примерчик свалки которую отобрала сейчас программа, проверил с точностью до запятой то что в исходном файле лога. а насчет проекции в памяти. Это вопервых мне интересно освоит, а во вторых думаю позволит мне компенсировать усложнение алгоритма парсинга тем что не надо будет файл по частям обрабатывать. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2011, 16:00 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авториспользуя проекции не надо будет файл по частям обрабатывать. в том том и дело что придется по частям там логика та же что и при обычной буферизации просто мы пишем не LoadBufferFromFile а MapFileToMemoryAddress но диапазон адресов куда мапить это физическая память совершенно та же что и при выделении буфера стандарным способом просто как только я первый раз услышал про мапинг то так же думал что все будет делаться автоматически и память можно будет выделить любого размера и долго потом пытался понять как же это можно сделать а оказывается никак понятно что если есть желание что-то новое изучить это хорошо ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2011, 17:15 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
если TraceID определяет нужную нам запись то можно просто всегда искать TraceID потом через пробел прочитать этот ид и если он изменился то завершить предыдущую запись и начать следующую так даже лучше не надо назад искать ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2011, 17:25 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсересли TraceID определяет нужную нам запись то можно просто всегда искать TraceID потом через пробел прочитать этот ид и если он изменился то завершить предыдущую запись и начать следующую так даже лучше не надо назад искать Все равно надо проверять кто сессию с этим TraceID открыл Иванов , Петров или Сидоров. Так что алгоритм делаю пока такой 1) Найти Иванова. Если Да то пункт 2, если нет то пункт 10 2) откатываюсь InStrRev на ближайший ]->UserInfo 3) откатываюсь InStrRev на [TraceId 4) определяю значение TraceId для данного пользователя для данной сессии 5) дальше ищу InStrRev на [TraceId тра-та-та]->IncomingTime 6) Нахожу начало этой строки 7) нахожу InStr на ближайший [YYYY.MM.DD 8) промежуток между 6 и 7 забрасываю в StrFound 9) Ищу следующее вхождение [TraceId тра-та-та]->. Если нахожу то повторение с пункта 6, если нет то пункт 1 10) Следующий фрагмент файла (файл) ну и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2011, 17:45 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, set fso = CreateObject("Scripting.FileSystemObject") set fin = fso.OpenTextFile(Input_File_Name) set fout = fso.CreateTextFile(Output_File_Name, True) section = "" hasUser = 0 do while not fin.AtEndOfStream line = fin.ReadLine if instr(line, ">IncomingTime") > 0 then if hasUser=1 then fout.Write section end if section = "" hasUser=0 elseif instr(line, ">UserInfo") > 0 then if instr(line, "john doe") > 0 then hasUser = 1 else hasUser=2 end if end if if nasUser<2 then section = section & CRLF & line ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''зачем сцеплять если читается сидоров вместо иванова '' не понятно на одной ли строке UserInfo и фамилия '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' endif loop fin.close fout.close ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2011, 21:43 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Забавная штука если имею размер буфера Х. При Х+1 получаю OUTOFMEMORY. Так вот если я создам две переменые и помещу в них информацию по объему равную Х, то никаких OUTOFMEMORY я не получаю. Тогда можно обойти ситуацию с разрывом данных в начале N-го фрагмента лога считанного из файла. просто держа 2 переменных strBuffer и strBufferOld. А в strBufferOld держать предидущей фрагмент N-1. О как интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 14:10 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
ПЕНСИОНЕРКАAlex_men, section = section & CRLF & line ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ''зачем сцеплять если читается сидоров вместо иванова '' не понятно на одной ли строке UserInfo и фамилия '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Прошу прощения не объясню, т.к. это не мой код. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 14:12 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторимею размер буфера Х. При Х+1 получаю OUTOFMEMORY это подозрительно и чему же равен Х? и как он был найден? теоретически конечно возможна ситуация когда в памяти есть два свободных маленьких куска но один большой из них сложить нельзя но вот только попасть в границу те угадать Х можно только в цикле увеличивая Х на 1 и выделять и освобождать память каждый раз ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 14:41 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторможно обойти ситуацию с разрывом данных в начале N-го фрагмента лога считанного из файла. просто держа 2 переменных strBuffer и strBufferOld. А в strBufferOld держать предидущей фрагмент N-1 смотря как сканировать буфер в моем примере так делать нельзя тк буфер целиком должен содержать две записи если это условие не используется то размер буфера надо брать большим только из тех соображений. что скорость чтения с диска гораздо выше когда буфер большого размера. по крайней мере я так измерил ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 14:46 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, не вижу >UserInfo ----------------------------пример 1-------------------- 2011.11.28 00:54:45:730][TraceID: TWDPWCC8R36HNU]->IncomingData\706 FЪКД2 TWDPWCC8R36HNU P Connection: Keep-Alive Accept: text/html, application/xhtml+xml, */* Accept-Encoding: gzip, deflate Accept-Language: ru-RU Cookie: exp_path=C%3A%5CUsers%5C%u0412%u0430%u0434%u0438%u043C%5CDesktop; __utma=179010226.226380545.1311577166.1321904062.1322427283.33; __utmz=179010226.1311577166.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=179010226.1.10.1322427283; SID=6a58efcbb44bba88asdb9bb087; hotlog=1; __utmc=179010226 Host: www.тра-та-та.ru Referer: http://www.тра-та-та.ru/ User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; BOIE9;RURU) T=R_Loader.Load7 # RequestInfo=12.16.1.5|12.16.1.9 ccSITE=R ----------------------пример 2--------------------------------------------------------------------------- 2011.08.18 10:57:39:895][TraceID: EPVI5K4Y1SGEVJ]->NewSessionUserInfo\292 SID = 2MVT8YHBALA8HCEEJABM3QN0J6TN28 UserKey = 100000286 ARMName = Иванов ----------------------строка не с UserInfo IDs = 100022338 [/SRC] ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 15:29 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Нашел народным способом тыка. думаю здесь играет размер стринг, а не памяти в целом я пробовал поставить Х=98 000 000. если ставил 99 000 000 то уже шло OutOfMemory. При этом две переменные спокойно съедают куски текста по 98 000 000. Возможно тут дело в типе переменной и размерности типа. Хотя по хелпу судя string должно вмещать в себя порядка 2 биллионов символов. Ну с учетом ASCII и не ASCII порядка биллиона. Сижу ковыряюсь в этом направлении. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 15:37 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
ПЕНСИОНЕРКА, аааа Понял Вас. Был введен в заблуждение разработчикаами и соответственно выдал не совсем верную информацию тут на форуме. После первичного разбора пачки логов наткнулся на несколько неприятных для меня вещей 1) Искомый фрагмент лога может переплетаться с другими фрагментами лога, не имеющими отношения к Иванову. 2) Как правило в таких (разбитых на куски) фрагментах присутствует не UserInfo, а NewSessionUserInfo. Таким образом поиск значительно усложняется. Во первых контроль надо делать еще и с учетом TraceId для выделения нужного мне фрагмента, во вторых выделение TraceId нужно делать с контролем по 2-м параметрам UserInfo и NewSessionUserInfo и в третьих нужно учитывать возможную фрагментацию искомого фрагмента лога (извиняюсь за тафталогию). С чем и ковыряюсь сейчас. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 15:48 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, а вот пытливый ум не дает мне покоя. В хелпе написано: "String - предназначен для хранения строковой (символьной) информации, т.е. попросту говоря - текста. Может хранить до 2 Гб. текста. Символ для обозначения - "$". " Классно, на деле порядка 100 мб и то в зависимости от запущенных на компе приложений.Гдето тут хитрая галочка не иначе ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 16:11 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Интересно а ктонибудь умудрялся впихнуть в стринг 2 Гб текста? Меня в принципе и один устроил бы :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 17:03 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
авторможет хранить до 2 Гб. текста это значит что размер строки ничем не ограничен в 32 бита может войти размер 4Гб но бейсик использует только знаковые типы те останется 31 бит или 2Гб ну а чтобы 2 Гб выделить надо их иметь свободными не знаю может на компе с 3Гб памяти и можно выделить строку большую чем 1Гб но кроме этой строки в проге есть еще данные которые тоже место занимают ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 17:10 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, Я понимаю, что на компе есть еще приложения и т.п. и т.д. Но вот вопрос пусть есть комп с 2Гб оперативы, пусть гиг отведен на систему, еще 500 м отдадим прочим прогам а как использовать оставшиеся 500. Или тут командует мелкософт и немытыми руками лезть не получится? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 17:33 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
парсер, уж больно геморойный поиск получается при чтении покускам. Но походу вариантов нет. Засучим рукова и приступим. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2011, 17:34 |
|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#18+
Alex_men, уф сделал, в общем разбор гига теперь стал минута 45 сек. зато ничего лишнего все по теме никаких вырваных кусков и обрезанных строк. Спасибо Вам всем за помощь. С НАСТУПАЮЩИМ НОВЫМ ГОДОМ! ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2011, 12:08 |
|
|
start [/forum/topic.php?all=1&fid=60&tid=2158182]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
255ms |
get tp. blocked users: |
2ms |
others: | 358ms |
total: | 710ms |
0 / 0 |