Article ID: 304227
This article explains how garbage collection works and how to tune the default behavior.
The MSXML parser internally uses a delayed freeing mechanism that is known as garbage collection to cause faster performance on multi-processor computers. For example, garbage collection frees the FreeThreadedDOMDocument object and the nodes from such documents. This mechanism is designed to reduce the computational cost of object destruction and improve the system throughput, which is important for server environments. However, depending on your application scenario, you may have to tune the default garbage collection behavior to optimize the performance of the application.
Generally, the garbage collection mechanism has two stages: partial garbage collection (NoFullGC) and full garbage collection (FullGC). Several internal factors trigger the partial garbage collection or full garbage collection process. Partial garbage collection can be interrupted, but full garbage collection cannot be interrupted until all of the objects that are marked for deletion are destroyed and the system resource is freed. Full garbage collection requires the suspension of all threads that use the MSXML parser in the host process. This makes the operation very expensive.
Full garbage collection may also cause a performance bottleneck when objects such as DOMDocument objects (in versions of MSXML earlier than MSXML 3.0 Service Pack 2) or FreeThreadedDOMDocument objects are frequently created and destroyed. In those specific scenarios, you can modify the registry settings to turn off full garbage collection.
The following settings are related to the garbage collection behavior when Msxml4.dll is the parser that you want to affect. The values that are shown are the default settings that are used if there are no registry entries.
To enable partial garbage collection, this registry setting should be 0x00000001.
Note Modification of these default settings affects all applications that use a particular version of the MSXML parser computer-wide. Only modify these settings with extreme caution and after extensive testing with all running applications.
PerformanceWhen you use a mix of the DOMDocument class and the FreeThreadedDOMDocument class in a multi-threaded application, you can gain both CPU and memory utilization by maintaining at least one active reference to at least one FreeThreadDOMDocument class in the process at all times. This prevents repeated initialization of various internal data structures, and allows the MSXML garbage collector to perform more efficiently. If you do not do this, too much memory may be used. The NoFullGC value determines whether full garbage collection is enabled. By default, the setting is 0, which means that full garbage collection is enabled. The NoFullGC value can be set to a non-zero value to disable the full garbage collection.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/297997/ )PRB: MSXML performance bottleneck in ShareMutex under stress
Article ID: 304227 - Last Review: June 22, 2014 - Revision: 3.0