Michael Peiffer

> Here're the detailed instructions on how get over it (given from support) It actually does work, which makes me think it doesn't have to see with the API. Once...

@oromand If you could provide a fork or patch i'd take a look at it :+1:

I see you already proposed a PR for this. Thank you for your effort!

I agree, a ThreadLocal definitely makes sense. I will look into this the next couple of days.

I added a per thread caching factory for `DocumentBuilder` similar to `XMLFactories`. DOMHandle now uses a DocumentBuilder through this Factory. Not sure if a `LSParser` also needs to be in...

> Regarding whether LSParser should be thread local, I would think that's only necessary if constructing the LSParser was also a performance hotspot in your testing, making caching advisable. Otherwise,...

Alright, I added another commit which adds threadlocal caching for `LSParser`. Because a `LSParser` is dependent and created through a `DocumentBuilder`, I could not use the exising `CachedInstancePerThreadSupplier` class. There...

By DOM initialization cost do you mean this [line](https://github.com/marklogic/java-client-api/pull/1053/files#diff-452f3c35f7586502326c7658dfae4ecdL393)? `DOMImplementationLS domImpl = (DOMImplementationLS) documentBuilder.getDOMImplementation();` At least in the java runtime this returns a static singleton, so there is not much...

I added another [patched.zip](https://github.com/marklogic/java-client-api/files/2852557/patched.zip) which shows the current performance flamegraph (just drop the file in your browser to navigate through the flamegraph). `DOMHandle.receiveContent` now consists of only parsing. I did...

Yes I can understand that especially the second commit adds up complexity for only a few improvements performance wise. I definitely want to get this right in a way both...