关于三种随机读取体式格局来讲，只需转变查询前提即可
XmlDocument:
var nodeList = doc.DocumentElement.SelectNodes("item[substring(title,1,1)='M'][position() mod 10 = 0]");
XPathNavigator:
var nodeList = nav.Select("/channel/item[substring(title,1,1)='M'][position() mod 10 = 0]");
Xml Linq:
var nodelist = from node in xd.XPathSelectElements("/channel/item[substring(title,1,1)='M'][position() mod 10 = 0]")
运用XPath，只需改一行代码。XPath也相称轻易控制，比SQL简朴很多。能够参考W3C Shcool的语法引见以及MSDN 针对XPath用户的LINQ To XML，一刻钟工夫你就可以控制个中奥妙。
但对XmlReader体式格局，可没那末轻易了，同样是读title以M开首，每十项取一项，想了半天，楞是没想出个文雅点的完成体式格局，只好云云：
代码
static List<Channel> testXmlReader2()
{
var lstChannel = new List<Channel>();
var reader = XmlReader.Create(xmlStream);
int n = 0;Channel channel = null;
Search:
while (reader.Read())
{
if (reader.Name == "item" && reader.NodeType == XmlNodeType.Element)
{
while (reader.Read())
{
if (reader.Name == "item") break;
if (reader.NodeType != XmlNodeType.Element) continue;
switch (reader.Name)
{
case "title":
var title = reader.ReadString();
if (title[0] != 'M') goto Search;
n++;
if (n % 10 != 0) goto Search;
channel = new Channel();
channel.Title = title;
break;
case "link":
channel.Link = reader.ReadString();
break;
case "description":
channel.Description = reader.ReadString();
break;
case "content":
channel.Content = reader.ReadString();
break;
case "pubDate":
channel.PubDate = reader.ReadString();
break;
case "author":
channel.Author = reader.ReadString();
break;
case "category":
channel.Category = reader.ReadString();
break;
default:
break;
}
lstChannel.Add(channel);
}
}
}
return lstChannel;
}
能够看到，代码构造发生了显著变化。为了作前提挑选，只得增添局部变量n，调整了实体类初始化，和到场鸠合语句的所在位置，以至被迫用了忘记多年的goto语句举行跳转(VB还好些)。营业逻辑渗进了代码细节的完成，用老赵的话说就是，一阵语法噪音的气味扑面而来。
XmlTextReader的完成代办类XmlTextReaderImp(internal的，不能直接用)，是个有上万行代码超等类，封装了大批直接对Xml字符级举行的操纵。由于操纵很靠近底层，宏观上很难找到太好的代码优化体式格局。假如挑选前提，也就是营业逻辑再庞杂一点，代码就会面目一新，可理解性可维护性如镜花水月。
如今再来比较一下时候机能：
XmlDocment 26ms XPathNavigator 26ms XmlTextReader 20ms Xml Linq 28ms
四种体式格局数据变得靠近了，Document和Navigator斲丧时候大幅下落，Reader体式格局下落不多，由于依然要重新Read究竟，削减的3ms能够以为由于削减了实体对象建立的开支。比较蹊跷的是Linq体式格局，竟然没有变化，落在了末了。
能够测试差别的查询前提，能看出这四种体式格局各有其机能极限，与Xml源的大小有关。比方关于前两种体式格局，就取决于XmlDocument.Load要领执行时候，在我本机上，Load这个Xml就须要23ms。Linq体式格局也不是雷打不动，假如处置惩罚的效果很少，执行时候会降1～2毫秒。
Document和Navigator体式格局，机能会随数据量增大而显著下落。很轻易猜到，是由于它们建立了很多无用对象的原因。看一下各体式格局内存占用便知，在数据悉数加载不挑选状况下，Document体式格局占用了23.3M摆布的内存，而Navigator体式格局只需22.9M摆布，这也诠释了为何Document体式格局机能下落更显著。Reader体式格局数据全加载，只需20.1M摆布内存，撤除顺序启动自身的开支，较前两种内存占用不到一半。Linq体式格局在内存方面又有冷艳表现，只比Reader体式格局多占了不到500k。
进一步的剖析，得出了进一步的结论：除非有迥殊须要，慎用XmlTextReader，它对变化预备不足，轻易失足。越发强烈推荐运用Linq体式格局，虽然某些状况下时候机能略低于Navigator体式格局，但优秀的内存占用表现，奠基了它的首选职位。而且我置信，将来的Linq To XML，还会越发壮大。
以上就是XML数据读取体式格局机能比较（二）的内容，更多相关内容请关注ki4网（www.ki4.cn）！
