> You will need to build samples and tests and then run sanityTest.pl > located in scripts/ on the data found in samples/data. I will also > run our internal tests to make sure there is no performance > degradation.
Got it. > Oh, it is actually more complicated than I thought. I don't think it > will be wise to back-port all this DOMMemoryManager-related changes. I wasn't sure either. > How about a simplified version, that boils down to the following: > > 1. Split kHeadAllocSize into kInitialHeapAllocSize and kMaxHeapAllocSize > with values from 3.0 branch. > > 2. Implement exponential growth until kMaxHeapAllocSize as in 3.0 (for > that you will need to add the fHeapAllocSize variable to the > DOMDocumentImpl class). > > While there won't be a way to tune fHeapAllocSize, the initial small > value and the subsequent growth should satisfy most applications. What > do you think? I think that's fine, but as I said, I'm the one who needs the lower values. ;-) It will take three allocations to get the value back to 64k where it is now, so I don't imagine that will hurt most applications too much, particularly if your other DOM patch really speeds up large document parsing by 20%. I'll prepare a patch against the 2.7 branch with your suggestion and test it. -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
