- One
XNameinstance to a differentXNameinstance - One
XNamespaceinstance to a differentXNamespaceinstance
XName and XNamespace implement the equality and inequality operators - which of course they do.
This concept is particularly relevant when working with XElement and XAttribute instances, where the same names might appear multiple times.
XName and XNamespace also implement the Implicit Operator that converts strings to XName or XNamespace instances.
This allows for automatically passing atomized instances as parameters to LINQ to Xml methods which then have better performance because of atomization. For example, this code implicitly passes an XName (with a value of "x") to the
Descendants method:
var root = new XElement("root",
new XElement("x", "1"),
new XElement("y",
new XElement("x", "1"),
new XElement("x", "3")
)
);
foreach (var e in root.Descendants("x").Where(e => e.Value == "1"))
{
...
}Name property in XName and XNamespace
in an internal static XHashtable<WeakReference<XNamespace>>. You can find the source code here:
Practical Implications
So how does atomization affect my application?- Element and Attribute Names: When you create elements or attributes using LINQ to Xml, the names are atomized. For example, if you create multiple elements with the same name, LINQ to Xml will store the name only once.
- Namespace Handling: Atomization also applies to XML namespaces. When you define namespaces in your XML, LINQ to XML ensures that each unique namespace URI is stored only once.
- Value Atomization: While element and attribute names are atomized, the values are not automatically atomized. However, if you're feeling adventurous and you frequently use the same values, you might consider implementing your own caching mechanism to achieve similar benefits. Now before you go off and write your own caching mechanism to cache values, consider that the .NET team has done a lot of work ensuring the caching of names is both thread-safe and performant. I've never found that I needed to do this though the largest xml documents I've had to work with are in the tens of MB's. If you're using much larger xml documents of hundreds of MB's or even 1 GB+ in size, then you may find this worthwhile.
Pre-Atomization
You might be thinking "..this is great, I can't do anything to improve performance here!". But there is. Unfortunately, even though you effectively can pass atomized instances to LINQ to Xml methods, there is a small cost. This is because the Implicit Operator has to be invoked. You can refer to the Atomization Benchmarks at the end of this post to get the details on some benchmarking I did. In a nutshell, the results show that pre-atomizing is just over 2x faster. That being said, we are talking about a couple hundred nanoseconds in the context of my test for an element with 3 child alements, each having an attribute and string content. The benefit of pre-atomization becomes much more evident with very large XML documents. Here is the xml used for test data in the benchmarks:<aw:Root xmlns:aw="http://www.adventure-works.com">
<aw:Data ID="1">4,100,000</aw:Data>
<aw:Data ID="2">3,700,000</aw:Data>
<aw:Data ID="3">1,150,000</aw:Data>
</aw:Root>The full code for the benchmarks can be found at this gist: Linq to Xml - XName Atomization Benchmark.cs
Atomization and ReferenceEquals
Let's take a look atXName as an example. There are two ways to directly create XName instances:
- The
XName.Get(String)orXName.Get(String, String)methods. See here - The
XNamespace.Addition(XNamespace, String) Operatormethod. See here
XDocument, XElement, and XAttribute instances.
Here is some code to demonstrate that there is a single atomized instance referred to regardless of how the instance was created.
// Note that these are not explicitly declared as const
string x = "element";
string y = "element";
var stringsHaveSameReference = object.ReferenceEquals(x, y);
Console.WriteLine(
$"string 'x' has same reference as string 'y' (expect true): {stringsHaveSameReference}");
// Create new XName instances (indirectly) thru XElement ctor
// using a string as the name
var xNameViaGet1 = XName.Get(localName, namespaceUri);
var xNameViaGet2 = XName.Get(localName, namespaceUri);
// Check if XName instances are the same
namesHaveSameReference = object.ReferenceEquals(xNameViaGet1, xNameViaGet2);
Console.WriteLine($"xNameViaGet1 is same reference as xNameViaGet2 (expect true): {namesHaveSameReference}");
// Create XName instances via XNamespace.Addition Operator
XNamespace ns = namespaceUri;
XName xNameViaNSAddition1 = ns + localName;
XName xNameViaNSAddition2 = ns + localName;
// Check if XName instances are the same
namesHaveSameReference = object.ReferenceEquals(xNameViaNSAddition1, xNameViaNSAddition2);
Console.WriteLine(
$"xNameViaNSAddition1 is same reference as xNameViaNSAddition2 (expect true): {namesHaveSameReference}");
// Create XElement and XAttribute using XName instances
XElement ele = new XElement(xNameViaGet1, "value1");
XAttribute attr = new XAttribute(xNameViaGet2, "value2");
// Check if XName instances in XElement and XAttribute are the same
namesHaveSameReference = object.ReferenceEquals(ele.Name, attr.Name);
Console.WriteLine(
$"ele.Name is same reference as attr.Name (expect true): {namesHaveSameReference}");
// Compare XName references that were created differently
namesHaveSameReference = object.ReferenceEquals(xNameViaGet1, xNameViaNSAddition1);
Console.WriteLine(
$"xNameViaGet1 is same reference as xNameViaNSAddition1 (expect true): {namesHaveSameReference}");
namesHaveSameReference = object.ReferenceEquals(xNameViaGet1, ele.Name);
Console.WriteLine(
$"xNameViaGet1 is same reference as ele.Name (expect true): {namesHaveSameReference}");
// Create 2 XElement instances with the same name of 'root' and same value
XElement eleViaCtor = new XElement("root", "value");
XElement eleViaParse = XElement.Parse("<root>value</root>");
// Note that the 2 XElements DO NOT have the same reference
bool xelementsHaveSameReference = object.ReferenceEquals(eleViaCtor, eleViaParse);
Console.WriteLine(
$"eleViaCtor and eleViaParse refer to same instance: {xelementsHaveSameReference}");
// However, their respective XName properties DO have the same reference
namesHaveSameReference = object.ReferenceEquals(eleViaCtor.Name, eleViaParse.Name);
Console.WriteLine($"eleViaCtor.Name and eleViaParse.Name refer to same instance: {namesHaveSameReference}");Atomization Benchmarks
These tests compared creatingXElement and XAttribute instances by either passing a string or an XName instance
to the constructors. Note that the memory allocations were identicial since they are all referring to the same XName instance.
Method | Mean | Error | StdDev | Ratio | Gen0 | Allocated | Alloc Ratio | ----------------------------------|---------:|--------:|--------:|------:|-------:|----------:|------------:| XNode_Construction_Passing_Strings| 355.9 ns | 3.69 ns | 3.45 ns | 1.00 | 0.0391 | 656 B | 1.00 | XNode_Construction_Passing_XName | 136.0 ns | 1.95 ns | 1.82 ns | 0.38 | 0.0391 | 656 B | 1.00 |The full code for the benchmarks can be found at this gist: Linq to Xml - XName Atomization Benchmark.cs
