unique/key constraint on non string field/attriibute slows validation 6x times
vs string attriibute
---------------------------------------------------------------------------------------------------
Key: XERCESC-1857
URL: https://issues.apache.org/jira/browse/XERCESC-1857
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (XML Schema)
Affects Versions: 3.0.1
Environment: Linux, Red Hat Enterprise Linux ES release 4 (Nahant
Update 4), gcc 3.4.6, 32 bits.
Reporter: Leonid G
I have prepared a fairly small schema with 'xs:unique' constraint on nested
element.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
<xs:element name="el1">
<xs:element name="el2">
<xs:element name="el3">
<xs:attribute name="key"
type="xs:string" use="required"/>
<!-- <xs:attribute name="key"
type="xs:unsignedInt" use="required"/>-->
</xs:element name>
<xs:unique name="uniqCreativeKey">
<xs:selector xpath="cam:creative"/>
<xs:field xpath="@key"/>
</xs:unique>
</xs:element name>
</xs:element name>
</xs:schema>
I need to validate a relatively large xml (~ 100Kb) against this schema.
Load + validation take about 10s and process consumes ~100Mb of memory. I am
using SAX, not DOM.
If I change schema definition slightly to make type of "unique" attribute to be
unsignedInt instead of string - than code runs ~ 1min:10 sec (7 times slower)
and also uses about 100Mb of RAM.
Thus I have two questions:
1. Why parser requires 100Mb of RAM to load and validate 100Kb file
2. Why changing attribute definition type from xs:string to xs:unsignedInt
slows validation 7 times?
I have built xerces myself from sources.
./configure --disable-shared --enable-netaccessor-socket
--enable-msgloader-inmemory --prefix=/mnt/builder/3rdParty/xml/xerces-c/3.0.1
--libdir=/mnt/builder/3rdParty/xml/xerces-c/3.0.1/lib.gcc-3.4.6
I can provide schema, xml and code that I am running.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
