SAX-парсер python vs DOM-парсер python. Парсим ФИАС-houses

[justhabrauser]

Вы немного не всё меряете.
Не в скорости (точнее — не только в ней) дело.
В конце DOM-парсера поставьте:

import sys
sys.getsizeof(tree)

[zoldaten]

Допустим. С чем теперь сравнить размер дерева?

[justhabrauser]

Да ни с чем.
С SAX точно нет смысла — там от размера XML размер парсера не зависит.
Но можно сравнить с размером исходного XML и сделать для себя выводы.
И прикинуть когда машина упадет в swap (а потом и в kernel panic) при обработке houses, ага.

[rSedoy]

Ну зачем выкладывать код такого качества, что вытекают глаза. Из-за этого пропадает желание разбираться всё ли правильно сделано, искать проблемные места и т.п.

[zoldaten]

В каком месте у вас выпадают глаза?

[rSedoy]

куча закомментированных мест, несоблюдение pep8, портянка append и использование except не по назначению

[zoldaten]

Пробежался по всем вашим комментам, ожидаемый ответ. Собирает плюсы. Понятно, что пепом здесь пока не пахнет, зато пахнет пеплом дымящихся голов.

Кстати, почему except не по назначению?

[rSedoy]

вы опубликовали код который будет прочитан кучей людей, потратьте время на его причесывания.
общий except зло, а в вашем случае, скорее всего должно быть что-то типа get для словарей

[WhiteBlackGoose]

А то есть остальное это ОК? То есть написать что-то типа

words = ['IFNSFL', 'IFNSUL' ... ]
for w in words:
    object.append(member.attrib[w] if w in member.attrib else None)

Это куда хуже, чем такой замечательный код, как у вас?

[zoldaten]

Так никто и не утверждает, что код идеален. Сравнение скорости работы парсеров это не туториал по курсу python.
Приятно, что сообщество активно борется за лучший код, но тыкать exceptoм это из области «у вас ус отклеился».
Конечно, тот, кто пишет про парсеры, не догадывается, что общий except это зло.

[GCU]

Можно кормить sax парсер через feed построчно непосредственно во время «очистки» файла БД, это будет быстрее, чем писать/читать новый обработанный файл. Более того — можно читать данные непосредственно из архива, распаковывая по мере обработки.

P.S. Зачем заморачивались с coroutine я не понял :)

[zoldaten]

1.Хорошая идея, построчно. Только вот база в одну бесконечную строку. Точнее в 2-е, 1-я xml заголовок.
2.Очищенный файл для выравнивая стартовых условий парсеров.

p.s. Корутин не работал, пришлось выяснять почему. Оказывается из питона 2.7 переехал в 3-й с удвоенными подчеркиваниями: cr.__next__()

[GCU]

Ну значит кормить блоками некоторой длины :)
Просто ваш «код очистки» вроде написан построчно.

Про условия — пожалуй нечестно сравнивать
SAX: дергание coroutine+print на каждое событие
DOM: csvwriter только тегов HOUSE.
Тогда уж пусть и SAX просто пишет CSV в startElement, если тэг HOUSE

[zoldaten]

Ну значит кормить блоками некоторой длины :)

Не уверен, что это будет работать быстрее.

Про условия — пожалуй нечестно сравнивать

Тогда в защиту DOM добавим то, что он выполняет конкатенацию элементов перед записью.

[GCU]

Не уверен, что это будет работать быстрее

DOM парсер тоже можно кормить по-частям, смысл в том, чтобы избавиться от чтения/записи дополнительного «очищенного» файла, особенно если он довольно большой.

Фишка SAX тут скорее в другом — он может писать результаты ещё до того, как файл обработан целиком, в то время как с DOM можно работать только после загрузки целиком (ну и сожрёт много памяти).

На современном железе чтение из архива с распаковкой может работать даже быстрее, чем чтение уже распакованного файла с диска. Судя по примеру — для обработки требуется всего один проход по файлу, так что в идеале программа будет ограничена лишь скоростью работы с диском.

[GCU]

Остается сожалеть, что данное достоинство не применимо к БД ФИАС, так как требуется предварительная работа с кодировками.

Вполне применимо, как я уже писал в комментарии.
Да, это не так красиво как просто дать имя файла. Придётся кормить парсер по-частям. Читать часть, чинить кодировку и кормить парсер :)

Для простого фильтра по тегам для SAX 27,5 ГБ ни о чем.
Тем более что парсер ничего кроме текущей «лексемы» не помнит.

DOM парсер для этого тоже подходит, его так-же можно кормить по-частям, но следить за объёмом «еды», как только размер достигнут — скормить ему фиктивный «конец», обработать «документ» и начать парсить новый, скормив ему фиктивное «начало». Это практически то-же самое, что было описано с разбиением файлов на маленькие в предыдущей статье, только без самих файлов (их не надо писать на диск и потом читать).

[zoldaten]

Это все так. Как говорится, осталось написать только код.
1.Кроме того, кодировка поломана только 10-15 случаях в файле 350Мб. Считаете, что для этого надо дробить при кормлении? Лишние условия для проверки увеличат время работы.
2. Следить за объемом еды для DOM. C какой целью, если заранее известен объем, при превышении которого программа вылетает. И как по частям кормить DOM, если он изначально заглатывает весь файл?

[GCU]

Считаете, что для этого надо дробить при кормлении? Лишние условия для проверки увеличат время работы.

Требует проверки, но не думаю что значительно. Можно поэкспериментировать на скрипте для «очистки», обрабатывая блоки в 4Кб, 8Кб, 16Кб… и т.д. вместо одной «строки»

И как по частям кормить DOM

В примере вы используете xml.etree.ElementTree.parse

Как это работает

Если заглянуть внутрь, там вот это:

def parse(source, parser=None):
    """Parse XML document into element tree.

    *source* is a filename or file object containing XML data,
    *parser* is an optional parser instance defaulting to XMLParser.

    Return an ElementTree instance.

    """
    tree = ElementTree()
    tree.parse(source, parser)
    return tree

Что ведёт к методу ElementTree

    def parse(self, source, parser=None):
        """Load external XML document into element tree.

        *source* is a file name or file object, *parser* is an optional parser
        instance that defaults to XMLParser.

        ParseError is raised if the parser fails to parse the document.

        Returns the root element of the given source document.

        """
        close_source = False
        if not hasattr(source, "read"):
            source = open(source, "rb")
            close_source = True
        try:
            if parser is None:
                # If no parser was specified, create a default XMLParser
                parser = XMLParser()
                if hasattr(parser, '_parse_whole'):
                    # The default XMLParser, when it comes from an accelerator,
                    # can define an internal _parse_whole API for efficiency.
                    # It can be used to parse the whole source without feeding
                    # it with chunks.
                    self._root = parser._parse_whole(source)
                    return self._root
            while True:
                data = source.read(65536)
                if not data:
                    break
                parser.feed(data)
            self._root = parser.close()
            return self._root
        finally:
            if close_source:
                source.close()

По сути это XMLParser, которого кормят по-частям кусками по 64Кб :)
Как еда заканчивается, parser.close() вернёт root

[zoldaten]

… переписать модуль python? По этой тропе недалеко и до разработки собственного языка.
Тем не менее, хорошо, что вы глубоко ныряете.

[TIEugene]

Даже SAX-парсер можно значительно ускорить правильным его выбором.

[zoldaten]

Читал предварительно вашу статью, впечатляет. Но у вас 10% материала отбраковано парсером…

[ShashkovS]

Простыню append'ов можно сделать так:

attr_names = [
    'HOUSEID', 'HOUSEGUID', 'AOGUID', 'HOUSENUM', 'STRUCNUM', 
    'STRSTATUS', 'ESTSTATUS', 'STATSTATUS', 'IFNSFL', 'IFNSUL', 
    'TERRIFNSFL', 'TERRIFNSUL', 'OKATO', 'OKTMO', 'POSTALCODE', 
    'STARTDATE', 'ENDDATE', 'UPDATEDATE', 'COUNTER', 'NORMDOC', 
    'DIVTYPE', 'REGIONCODE'
]
for attr_name in attr_names:
    object.append(member.attrib.get(attr_name, None))            

[soymiguel]

Append не нужен (а здесь даже и вреден).

object = [member.attrib.get(attr_name, None) for attr_name in attr_names]

[zoldaten]

Объединено с предыдущим комментом и добавлено в код. Выигрыш 20 сек!

[sshikov]

>То есть в тегах STRUCNUM либо HOUSENUM попадались дома с буквой, записанной в странной кодировке (не UTF-8 и не ANSI, в которой сформирован сам документ):
Вообще-то, файлы ФИАС в utf-8, о чем написано в заголовке. Откуда тут про ANSI?

Вы далеко не первый, кому понадобился ФИАС, и думаю даже не тысячный — тех кто эту процедуру проходил, их очень много. Даже у нас в компании я знаю минимум три случая импорта ФИАС независимо разными проектами ;) Но при этом я не помню, чтобы сталкивался с упоминаниями побитой кодировки. Может у вас предыдущие шаги процесса что-то портят?

[zoldaten]

Как ни странно, БД обрабатывается и в utf-8 и ANSI, и обе спотыкаются на вышеуказанном.
Проблема именно с HOUSES, с файлом адресов такого нет.

Вы для каких целей ФИАС используете?

[sshikov]

>Как ни странно, БД обрабатывается и в utf-8 и ANSI
Это странно. А можете показать точно то место, где есть проблемы с кодировкой? Ну скажем смещение от начала файла?

>Вы для каких целей ФИАС используете?
Ну если совсем просто — то для нормализации адресов. Чтобы разрешать неопределенности в написании адреса, нужно знать, какие адреса реально существуют. ФИАС в этом смысле не идеальный, но это лучшее, что у нас есть.

[zoldaten]

Cмещение от начала файла:
#line 2, column 656 — sax parser, использует «utf-8»
#line 2, column 17232734 — dom parser, использует «ANSI»

[sshikov]

Ничего похожего в выгрузке от 7 октября не наблюдаю. Кодировка реально utf-8 (причем с BOM).