Olabusayo Kilo created DAFFODIL-3092:
----------------------------------------
Summary: NS.apply(String) reparses a URI on every call causing
avoidable allocation
Key: DAFFODIL-3092
URL: https://issues.apache.org/jira/browse/DAFFODIL-3092
Project: Daffodil
Issue Type: Improvement
Components: Unparsing
Affects Versions: 4.2.0
Reporter: Olabusayo Kilo
Assignee: Olabusayo Kilo
Fix For: 4.3.0
During unparse, resolving each incoming element name to its ElementRuntimeData
(NextElementResolver.nextElement, in PartialNextElementResolver.scala) calls
NS(namespace) once per element whenever the infoset source reports
namespaces, both OnlyOnePossibilityForNextElement.maybeNextElement and
SeveralPossibilitiesForNextElement.maybeNextElement do this unconditionally.
NS.apply(String) (Namespaces.scala) previously handled every call, including
repeats of the exact same namespace URI string, by:
1. Calling URI.create(nsString) to parse the string into a java.net.URI.
2. Looking that URI up in a uniqueness cache implemented as a
ReentrantReadWriteLock-guarded WeakHashMap (intended for schema-compile-time
use, where NS objects are constructed relatively rarely).
Since the same handful of namespace URI strings recur once per element across
an entire document, every single element paid a full URI parse plus a lock
acquisition, even though the result was always the same cached NS instance.
java.net.URI-related allocation was 121 MB on a 100k-element namespaced
document (10 iterations), entirely attributable to this path. Execution-sample
profiling on a related unparse benchmark showed URI/NS resolution responsible
for a double-digit percentage of total sampled CPU time on some workloads.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
