I have not worked with KML, but the Linq to XML libraries are essentially a substitute to the XmlDocument, XmlElement, etc, model in System.Xml. From a memory perspective, I do not know if they are any better than your current solution.
One approach I often use is to create a set of data classes that represent the Xml document and then use the XmlSerializer to turn the objects into Xml. I'm fairly this implementation is not a great memory hog and I think, for your purposes, this may make sense.
Here's a quick example. Say I wan to create the following Xml:
<Packages>
<Package Name="A">
</Package>
<Package Name="B">
<Dependencies>
<Dependency Package="C" />
<Dependency Package="A" />
</Dependencies>
</Package>
<Package Name="C">
<Dependencies>
<Dependency Package="A" />
</Dependencies>
</Package>
</Packages >
You can create the following classes:
class Package
{
private List<Dependency> dependencies = new List<Dependency>();
public string Name { get; set; }
public List<Dependency> Dependencies { get { return dependencies; } set { dependencies = value; } }
}
class Dependency
{
public string Package { get; set; }
}
Using the System.Xml.Serialization.XmlSerializer class, you can turn a List into the Xml above.
So if you create an object model for KML that easily maps to the actual KML, like the example above, it should be a somewhat straightforward implementation.