Ah, my mistake, I could not quite detect what you meant from your original post.
I noticed the sentence, "Do we really need to "count" more than 2^32 nodes in a document, or be able to index into more than 2^32 of character data?" and thereby became concerned that we would be placing a 4GB (or whatever) size limit on instance documents. Based on what I understand you to be saying now, I can agree 32 bits is more reasonable for the purposes you listed. Not understanding the code too well, I feel the need to ask what happens if these 32-bit size values are also used in the code for the memory managers? Could that limit the size of DOM tree that could be used when writing a new XML document to an unreasonably small value for larger instance documents? --Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 10, 2005 2:10 PM To: [email protected] Subject: RE: Need for XMLSize_t? > My enterprise works with very large instance documents that are rich in > tags. Currently some of our large documents are 750 MB and are growing fast > as more data is added to the XML feeds and more users subscribe to our > services. > > If we went over 2/4/whatever GB limit that these 32-bit types impose, that > would be very bad. Therefore I advocate making sure a library compiled as > 64-bit shares the same traditional large file safety that people have come > to expect in other 64-bit libraries. If this convention is not followed, > what is the point of having 64-bit Xerces in the first place? It's not as simple as that. We are talking about counts of nodes, not sizes of nodes, or the amount of memory that's addressable. For example, it's roughly: 4,294,967,296 nodes per document 4,294,967,296 characters per string value (8,589,934,592 bytes) 4,294,967,296 nodes per node list etc. I think you get the idea. Even with 64-bit addressing, the amount of memory consumed by a document that went over these limits would be huge. I think it's also worth mentioning that, if we go to 64-bit values everywhere, every document will pay the price in potentially overhead for the few documents that manage to hit these limits. Of course, it's always possible to redefine the typedef to be a 64-bit value, if you should need to. That's why typedefs are a "good thing" and we should carefully examine the use of XMLSize_t before we make any change. Dave ___________________________________________________________________ The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
