BuryCommonerНа Java только начал писать. Прочитал, что стандартный XPath имеет низкую производительность на глубоких деревьях.

IMHO & AFAIK Не бывает абстрактной низкой или высокой производительности
В лучшем случае, может быть:
a) достаточная производительность для выполнения конкретной бизнес задачи
b) и не достаточная производительность также для конкретной задачи

Если код требуется выполнять раз в сутки, то и минуту подождать можно, если раз в год, то можно и час подождать )))
А вот если 100500 раз в секунду, то тогда, скорее всего, нужно вкладывать бабло в программистов, которые код на Assembler с SSE и прочими оптимизациями перепишут ))) Или купить пару стоек в дата центре и соорудить какой нибудь распределенный супер-мега кластер типа гугловского или амазоновского )))

BuryCommoner...стандартный XPath...
Подскажите, есть ли полноценный и быстрый XPath для Java. Наподобие, например, MSXML6 для Windows.
IMHO За гранью добра и зла
1. "стандартный XPath". Это как "стиральный порошок Tide против обычного стирального порошка". Хотя, скорее, тут "если Вы не видите разницы, то покупайте Досю". Т.к., подозреваю, что 80-90% кода в реализациях XML от различных вендоров полностью совпадают или взято из бесплатных источников (типа xalan/xerses)
2. Я так понимаю M$ XML совершенно для других языков. Т.ч. это обсуждения достоинства вкусов банана vs яблока или мягкого vs теплое. Ну и никто не воспрещает его использовать и с Java (например через связку Java - COM - M$ XML или Java - C - M$ XML), если такая потребность _для_бизнеса_ реально есть, а не выдумана
3. Ну и назвать "быстрым" любую реализацию с DOM, хоть на Java, хоть на C, у меня тоже язык не поворачивается.
пользовался jaxen - пример для dom
может бегать не только по DOM

Мне кажется, что если действительно стоит проблема performance, то DOM сразу же нужно отправлять на помойку. И по производительности, но в первую очередь, по потреблению памяти

Не уверен, но даже XML трансформация умеет через SAX работать (давно с этим сталкивался, т.ч. полной уверенности нет, нужно смотреть документацию по библиотекам)

Если документы могут достигать сотен мегабайт (или нужно обрабатывать сотни тысяч мелких документов), то мне сложно представить продуктовую среду с использованием DOM которая не будет "тормозить" и замусоривать heap (т.е. все равно тормозить, только уже на GC).

IMHO & AFAIK

https://habrahabr.ru/post/128175/

Жесть какая-то. И сама проблема (бага) жесть (если она конечно существует), но решение еще более "жесткое"

Совет клонировать node перед использованием xpath.... волосы дыбом встают.

"Туда сюда обратно, тебе и мне приятно" ( C ) мурзилка

но на jdk1.8.0_65 поведение такое же.

Как я понимаю, они все время вынуждены пересоздавать DTM для всего документа.
Если между вызовами XPath документ не меняется, то можно этого и не делать.

Если использовать org.apache.xpath.XPath или org.apache.xpath.CachedXPathAPI, то вроде такого (тормознутого на нодах) поведения нету. Но нужно внимательно доку читать, я как-то многого про DTM и XPathContext не понял (((

Я с XPath близко не разбирался. Использовать - использовал, но на производительность было глубоко пофиг.

lleming...для дефолтового из jdk xml процессора...
у меня "дефолтный" как раз apache