Parser3 изнутри, немного истории

Александр Петросян (PAF) 05.12.2005 11:22 / 05.12.2005 11:26

на свете много хороших исходных кодов.
если есть возможность, думаю, стоит на них поучиться.
программистам на C++ очень советую поучиться на исходниках SSCLI (Microsoft).

Parser совсем небольшой и несложный проект, но и тут есть что взять:
скажем, проследить в cvs.parser.ru, как в ходе истории менялась реализация класса String:
имелось три разных версии:
* изначально связный список из блоков-указателей на кусочки,
* потом вышеописанная CORD-реализация дерева букв из libgc + хитрый способ хранения tainting
* потом текущий вариант с двумя CORD и оптимизацией простых случаев.

конечно, тут важно, что клиенты класса String ничего не замечали, остальной код не менялся.

работа с памятью, это отдельная песня:
* изначально было принято решение не освобождать ненужные куски памяти, их учёт требовал больше сил, чем представлялось выгоды
* потом была сделан, но не выпущен, вариант с учётом ссылок, см. здесь, ветка autoptr. такой подход относительно несложен в реализации, однако недостатки подхода перевесили достоинства:
-кольцевые ссылки. при определённой дисциплине пользователей эту проблему можно обойти, однако этой самой дисциплины, понятно, нет. а также абсолютная необходимость в обратной совместимости.
-цена подхода оказалась не очень: профайлер упорно указывал на тормоза в точке учёта ссылок
-хотя в некоторых языках так и сделано, их архитекторы всё равно стремятся или к комбинированному подходу (refcounting+gc — python) или к чистому gc (java, .NET).
* сейчас используется libgc, без описания типов объектов
* в будущем, если понадобится, есть куда ускориться: в libgc есть поддержка описаний объектов, а значит можно в два-три раза ускорить сборку мусора, просто предоставив менеджеру памяти эти описания. сделать совсем несложно. в .NET сделано ровно так.

о возможном кэшировании байткода уже уже писал.
скэшировать можно и в память, и на диск.

---