|
|
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Fr0sT-Brutal cptngrb основная мысль - меньше строк в потоках. Да, т.к. это основной perf-киллер. Выделить строку, заполнить, помацать счетчик ссылок через блокировку, удалить строку... парсинг по месту конечно быстрее будет Ситуация усугубилась с распространением многопоточности и серверной обработки Причём документы могут быть небольшие, но их будет тонна ) Кто знает, может быть дойдут руки - напишу парсер JSON и/или XML По крайней мере идея есть вообще бомбическая - задействовать thread var и стековую память - то есть вообще отказаться от синхронизации на куче TTinyObject уже позволяет не только конструироваться в стековой памяти, но и резервировать память под рабочие буферы Пока просто необходимости в этом не было ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2020, 15:22 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Fr0sT-Brutal Да, т.к. это основной perf-киллер. Однопоточный ММ, на самом деле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2020, 15:31 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
SOFT FOR YOUСитуация усугубилась с распространением многопоточности и серверной обработки ситуация усугубилась с распространением "программистов", не представляющих объём работы, выполняемый каждой из написанных ими строчек. SOFT FOR YOUПо крайней мере идея есть вообще бомбическая - задействовать thread var и стековую память - то есть вообще отказаться от синхронизации на куче Давно реализовано во всех менеджерах памяти, включая системный линухов. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2020, 15:33 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Kazantsev Alexey, FastMM, даже 5 - аналогично работает через синхронизацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2020, 15:34 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov ситуация усугубилась с распространением "программистов", не представляющих объём работы, выполняемый каждой из написанных ими строчек. Так их всегда было много Dimitry Sibiryakov Давно реализовано во всех менеджерах памяти, включая системный линухов. Мне кажется ты не понял суть Менеджер памяти - куча Для Delphi неблокирующий только ScaleMM. И BrainMM, до которого всё руки не дойдут Даже в этом случае менеджмент накладывает существенный оверхед Полный парсинг и конструирование через память на стеке и thread var - это совсем другое дело ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2020, 15:38 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
SOFT FOR YOUМне кажется ты не понял суть Менеджер памяти - куча Современный менеджер памяти - несколько куч по числу потоков/ядер. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2020, 16:13 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, SOFT FOR YOU Для Delphi неблокирующий только ScaleMM. И BrainMM, до которого всё руки не дойдут Даже в этом случае менеджмент накладывает существенный оверхед Полный парсинг и конструирование через память на стеке и thread var - это совсем другое дело ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2020, 16:24 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
SOFT FOR YOU, нафиг конструирование, а вот специальный SAX-парсер, только определяющий начало и конец данных, - это, да, другое дело ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2020, 09:43 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Aleksandr Sharahov, Честно говоря, не понял, о чём мессейдж ) Конструирование нужно потому, что конструирование обычно в куче. Можно ухищряться, делать пул объектов. А можно выделить нужное количество памяти на стеке. Или в thread var буфере ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2020, 09:57 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
SOFT FOR YOU Aleksandr Sharahov, Честно говоря, не понял, о чём мессейдж ) Конструирование нужно потому, что конструирование обычно в куче. Можно ухищряться, делать пул объектов. А можно выделить нужное количество памяти на стеке. Или в thread var буфере Речь о том, что для работы с данными строки сама строка не нужна, нужны лишь ее данные, которые и так уже доступны в тексте, который мы парсим. Ну, если ты понял, о чем я ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2020, 10:03 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Aleksandr Sharahov, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2020, 10:48 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Aleksandr Sharahov, На этой концепции и строится CachedTexts Фишка в том, что ты не просто работаешь с памятью, у тебя есть ещё "строки", представляющие из себя пару <указатель,длина>, и поверх этих строк есть куча быстрых функций, перевода в число, дату, Trim, поиск символа или подстроки, в том числе без учёта регистра А конструирование нужно потому, что свой парсер поверх этой концепции нужно наследовать от класса. И конвертация кодировки, в случае необходимости, так же происходит в классе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2020, 11:09 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
SOFT FOR YOU ... А конструирование нужно потому ... самый быстрый этап обработки - тот, которого нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2020, 11:30 |
|
||
|
Быстрый парсер текста
|
|||
|---|---|---|---|
|
#18+
Aleksandr Sharahov, В теории да На практике удобно, когда есть некий класс парсера Который в случае необходимости конвертнёт исходную кодировку в ту, которую ты ожидаешь, позаботится о буферзации если ты парсишь гигабайтные тексты Разумеется. Просто в данном контексте подход на основе наследуемых классов и конструирование на стеке/TLS - весьма эффективный подход ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2020, 12:54 |
|
||
|
|
start [/forum/topic.php?fid=58&msg=40007962&tid=2037934]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
77ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 244ms |
| total: | 449ms |
| 0 / 0 |
