I had not tried to make it as small as 8. In my local copy, I changed the 16 to 12. I did not try any other values.
None of my stylesheets attempted to use key() or tokenize(). I do have plenty of <xsl:value-of select='ancestor-or-self::@some_attribute' />, however. tlj Timothy Jones - Sr. Systems Engineer, Development (813) 637-5366 - Syniverse Technologies There are 10 types of people in the world: Those that understand binary and those that don't. -----Original Message----- From: Theis, Karsten [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 3:46 AM To: Timothy Jones; [email protected] Subject: AW: "Best practice" for setting IDENT_DTM_NODE_BITS and DEFAULT_BLOCKSIZE Hi Timothy, I tried several values of IDENT_DTM_NODE_BITS (always recompiling all files). The Problem was, that with IDENT_DTM_NODE_BITS = 8 I got an "Out of memory error" instead "no more DTM IDs available". After changing the DEFAULT_BLOCKSIZE to 64 this error was gone too. I'm not sure, but maybe this kind of xslt code is the problem: <xsl:key name="PropertyIndex" match="Property_value" use="@id"/> ... <xsl:variable name="Properties" select="key('PropertyIndex', str:tokenize(Simple_property_association/Specified_value, ' '))"/> The template using the variable "Properties" is called about 100000 times. Any ideas? Ciao, Karsten > -----Ursprüngliche Nachricht----- > Von: Timothy Jones [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 6. April 2006 15:37 > An: Theis, Karsten; [email protected] > Betreff: RE: "Best practice" for setting IDENT_DTM_NODE_BITS > and DEFAULT_BLOCKSIZE > > Hi Karsten, > > I had a similar problem (transforming large DOMs built in > memory, not read from disk), and that solution works for me > also. However, I did not find it necessary to change > DEFAULT_BLOCKSIZE (indeed, I didn't even know about that > constant until your post). > > When I asked about making IDENT_DTM_NODE_BITS a configurable > item (via system property, etc), I was told that the system > shouldn't run out of DTM_IDs anymore, and therefore I should > not have had to make the change. > There is a comment in the code that says it is a compile-time > setting, so you must make sure you build ALL of xalan.jar > after modifying this constant (you have probably read that > already). My understanding is that because > IDENT_DTM_NODE_BITS is a final int, the compiler copies the > value into other xalan classes. Of course, you could make it > non-final (modifiable), but then you lose the speed that > comes with it being a final int. I would wonder how much of > a hit making it non-final would really be. > > Unfortunately, I haven't had time to put together a test case > to "prove" > that the problem still exists. > > > > tlj > > Timothy Jones - Sr. Systems Engineer, Development > (813) 637-5366 - Syniverse Technologies > There are 10 types of people in the world: > Those that understand binary and those that don't. > > > > -----Original Message----- > From: Theis, Karsten [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 06, 2006 3:31 AM > To: [email protected] > Subject: "Best practice" for setting IDENT_DTM_NODE_BITS and > DEFAULT_BLOCKSIZE > > > Hi, > > I'va had trouble with "no more DTM IDs available" while transforming > very large XMl documents (> 200 MB). > > I found a solution by changing IDENT_DTM_NODE_BITS to 8 (in > com.prostep.xml.dtm.DTMManager). > > After this change I got an "out of memory error", and I changed > DEFAULT_BLOCKSIZE to 64 (in com.prostep.xml.dtm.ref.DTMDefaultBase). > > Now it works fine and the performance has increased dramatically. > (I think the problem was, that i use str:tokenize very often, and this > consumes DTM Ids, but I'm not sure.) > > > Now my question: > Is there a a "Best practice" for setting the XALAN constants? > > > Thanks, > Karsten > >
