|
Работа с большими текстовыми файлами.
|
|||
---|---|---|---|
#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 |
|
|
start [/forum/topic.php?fid=60&msg=37568583&tid=2158182]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
78ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 204ms |
0 / 0 |