в библиотеке libxml и libxml автор допустил ошибки при работе с памятью

Александр Петросян (PAF) 28.12.2004 16:53 / 28.12.2004 16:56

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

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

мы заметили это на двух проектах на разных площадках с разными OS.
нашим клиентам не понравилось.

мы приняли решение: не доверять библиотеке libxml и libxsl освобождать память и не доверять им принимать решение о типе выделяемого плока (atomic/mixed).

это существенно ускорило выполнение скриптов (не выполняется free).
незначительно замедлив сборку мусора.
соответственно, суммарно, даже получился некий выигрыш по скорости [по нашим тестам меньше, чем по вашим, но, конечно, это зависит. нам было важно, чтобы не было замедления].

вывод 1: если вам дорогА занимаемая память, сделайте ещё сколько-то сборок мусора в ключевых местах, память освободится.
^вывод[$вывод]: конечно, ценой некоторого замедления.

вывод 2: время идёт, и рост требований приложений, это нормально. а память, как и всё, дешевеет.
скажем, сравните проект с XML и без него. удобнее писать с XML, хотя памяти уходит существенно больше, поставить память в машину (или заплатить на копейку больше хостеру) это дешевле, чем тратить кучу усилий, работая по старинке.

для радикалов: лучше библиотеки, чем libxml+libxsl пока нет.

для рисковых парней, которые никогда ошибок не видели и думают, что беда их обойдёт, и их клиент никогда не будет расстроен непонятной ошибкой на заглавной странице посещаемого сайта: снимите комментарии с этих строк pa_globals.C:

#define PA_WORKAROUND_BUGGY_FREE_IN_LIBXML_GC_MEMORY
#define PA_WORKAROUND_BUGGY_MALLOCATOMIC_IN_LIBXML_GC_MEMORY

---