http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405713178230#c7653533082577736149
http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405713588100#c5428060724828928348
Отмечу - я говорю не только про "копеечную" сериализацию, измеряющуюся сотнями килобайт или единицами мегабайт. Но и о данных которые измеряются десятками/сотнями, а то и тысячами мегабайт.
Чем ещё плоха "бинарная сериализация"? Или dfm-like использование TPersistent.
А тем что документ ПО-ЛЮБОМУ надо грузить в память и там уже обрабатывать.
Альтернатива?
Альтернатива есть - SAX-подобные техники.
Речь НЕ ИДЁТ ТОЛЬКО об xml, но xml и xlslt - это ХОРОШИЙ пример, на который СТОИТ смотреть.
Но не факт, что их СТОИТ напрямую использовать.
Но схема примерно такая:
Reader -> Filter1 -> Filter2 -> ... -> FilterN -> Writer
Фильтры принимают "поток данных" типа StartElement, FinishElement, StartRecord, FinishRecord, AddAtomicAttribute и принимают решения - что фильтровать, а что добавлять к этому "потоку данных".
При этом фильтры могут, что-то "буферизовывать", а что-то "обрабатывать на проходе".
Таким образом - фильтрам в общем случае НЕ НАДО "буферизовывать" ВЕСЬ документ в памяти.
Такое конечно - ТОЖЕ встречается. Если "для принятия решения" о трансформации данных "в НАЧАЛЕ документа" надо дождаться данные "находящиеся в его КОНЦЕ". Но это - ИСКЛЮЧИТЕЛЬНЫЕ случаи.
ОБЫЧНО - достаточно "буферизовывать", что-то "сильно локально".
Ну это я по своей более чем 20-тилетней практике "обработки документов" говорю.
Возможно у кого-то существует другая практика.
Ну и "вдогонку" - http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405715420072#c7870653359150528237
И ещё мнение - http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405716053630#c8590241723163075829
http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405713588100#c5428060724828928348
Отмечу - я говорю не только про "копеечную" сериализацию, измеряющуюся сотнями килобайт или единицами мегабайт. Но и о данных которые измеряются десятками/сотнями, а то и тысячами мегабайт.
Чем ещё плоха "бинарная сериализация"? Или dfm-like использование TPersistent.
А тем что документ ПО-ЛЮБОМУ надо грузить в память и там уже обрабатывать.
Альтернатива?
Альтернатива есть - SAX-подобные техники.
Речь НЕ ИДЁТ ТОЛЬКО об xml, но xml и xlslt - это ХОРОШИЙ пример, на который СТОИТ смотреть.
Но не факт, что их СТОИТ напрямую использовать.
Но схема примерно такая:
Reader -> Filter1 -> Filter2 -> ... -> FilterN -> Writer
Фильтры принимают "поток данных" типа StartElement, FinishElement, StartRecord, FinishRecord, AddAtomicAttribute и принимают решения - что фильтровать, а что добавлять к этому "потоку данных".
При этом фильтры могут, что-то "буферизовывать", а что-то "обрабатывать на проходе".
Таким образом - фильтрам в общем случае НЕ НАДО "буферизовывать" ВЕСЬ документ в памяти.
Такое конечно - ТОЖЕ встречается. Если "для принятия решения" о трансформации данных "в НАЧАЛЕ документа" надо дождаться данные "находящиеся в его КОНЦЕ". Но это - ИСКЛЮЧИТЕЛЬНЫЕ случаи.
ОБЫЧНО - достаточно "буферизовывать", что-то "сильно локально".
Ну это я по своей более чем 20-тилетней практике "обработки документов" говорю.
Возможно у кого-то существует другая практика.
Ну и "вдогонку" - http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405715420072#c7870653359150528237
И ещё мнение - http://programmingmindstream.blogspot.ru/2014/07/blog-post_16.html?showComment=1405716053630#c8590241723163075829
Комментариев нет:
Отправить комментарий