我们公司里面的树型控件一直用的是应用比较广泛的开源控件WebFXLoadTree。
可能是因为之前的系统里面树型数据比较少,每次load也都不会超过20条数据的那种,所以一直都没有发现有性能问题,近来我们做的这个系统,里面有这样的一个树型,它会load一个村里面的若干个家庭,大概有二百至三百条数据,问题就出来了,需要load很长时间。
那么我简单的做了个测试,
数据量:358条
包括后台查询的时间再到数据展现的时间 : 8.9秒,
吓得我出了身冷汗,这种速度客户是无论如何都接受不了的。本来想说服客户是否可以通过其他方式来查询,比如列表分页,但是客户已经习惯之前的开发的cs系统的操作,他们习惯左边有树形来展开家庭,再通过家庭看每个家庭所对应的人。没办法,说服不了客户,那就只能试着看能否优化它。
简单分析了下,后台数据生成xml这一块才20多毫秒,看来性能瓶颈在前台部分,那么就从解析xml这里开始下手, 下面我会贴出一些简短的代码,因为代码太长。
我在前台测试速度的方法是 用new Date().getTime(),
那么从解析xml开始入手。_startLoadXmlTree(); 这个方法也就是通过xmlhttp来返回一个xml,再将遍历这个xml,将里面的属性值当参数传给真正的节点对象,一个一个的装载进去。
解析xml花的时间很少,通过一小程序段一小程序段的测试,发现关键就在是在遍历过程中new 节点对象的时候,再将一个一个节点add到父节点里面去的时间花费的很长,
这个时间花了7秒多钟,那接着再看add方法,它的add方法是继承WebFXTreeAbstractNode.prototype.add方法。
这个方法主要是设置了一些图片对象的位置,再组装好一个节点所对应的html字符串,再将这个字符串insertHTMLBeforeEnd 进去,所以节点是一个一个生成的,每次在遍历的时候又设置已经生成好的节点的里面html对象一些属性,比如图片等等。而每次设置这些html对象的时候,都是多次通过document.getElementById来取 ,那么性能瓶颈就在这里。
因为这个树型的复杂性,它所对应的html结构也是相当复杂的,也就是说在html标签非常多,结构非常复杂的情况下,我在358个节点里面遍历,也就是在非常复杂的html结构(并且这个html结构是持续变多的,因为节点是慢慢增多的)中,多次通过document.getElementById来寻找这个html结构里面的一个html对象,就造成了这个性能瓶颈,因为document.getElementById也是要遍历整个html文档的节点,再通过id的匹配来找的。那么这样一下来,在这种环境下就造成了性能问题。
也许当时作者为了面向对象的封装性而忽视了这个性能瓶颈。
一下午就这样过去了,看来作者当时的设计导致我不可能去优化这棵树,我得自己去写一个,
具体思路如下:
就是当后台传给一个xml的时候,我解析xml,将所有节点的所对应的html叠加起来设置好,再一起加载到父节点中,从而避免上面的做法。ok简单设计了一下,我的想法应该可行,明天我会接着将自己的树的思路写出来。
今天学习总结:
1.WebFXLoadTree不适合用于每次装载数据量超过100的情况,也希望大家有遇到我这样需求的时候好好考虑。
(未完待续)希望大家能给我更多好的建议,此上只是我个人的一些理解,有不当之处希望大家指出。
可能是因为之前的系统里面树型数据比较少,每次load也都不会超过20条数据的那种,所以一直都没有发现有性能问题,近来我们做的这个系统,里面有这样的一个树型,它会load一个村里面的若干个家庭,大概有二百至三百条数据,问题就出来了,需要load很长时间。
那么我简单的做了个测试,
数据量:358条
包括后台查询的时间再到数据展现的时间 : 8.9秒,
吓得我出了身冷汗,这种速度客户是无论如何都接受不了的。本来想说服客户是否可以通过其他方式来查询,比如列表分页,但是客户已经习惯之前的开发的cs系统的操作,他们习惯左边有树形来展开家庭,再通过家庭看每个家庭所对应的人。没办法,说服不了客户,那就只能试着看能否优化它。
简单分析了下,后台数据生成xml这一块才20多毫秒,看来性能瓶颈在前台部分,那么就从解析xml这里开始下手, 下面我会贴出一些简短的代码,因为代码太长。
我在前台测试速度的方法是 用new Date().getTime(),
那么从解析xml开始入手。_startLoadXmlTree(); 这个方法也就是通过xmlhttp来返回一个xml,再将遍历这个xml,将里面的属性值当参数传给真正的节点对象,一个一个的装载进去。
解析xml花的时间很少,通过一小程序段一小程序段的测试,发现关键就在是在遍历过程中new 节点对象的时候,再将一个一个节点add到父节点里面去的时间花费的很长,
这个时间花了7秒多钟,那接着再看add方法,它的add方法是继承WebFXTreeAbstractNode.prototype.add方法。
这个方法主要是设置了一些图片对象的位置,再组装好一个节点所对应的html字符串,再将这个字符串insertHTMLBeforeEnd 进去,所以节点是一个一个生成的,每次在遍历的时候又设置已经生成好的节点的里面html对象一些属性,比如图片等等。而每次设置这些html对象的时候,都是多次通过document.getElementById来取 ,那么性能瓶颈就在这里。
因为这个树型的复杂性,它所对应的html结构也是相当复杂的,也就是说在html标签非常多,结构非常复杂的情况下,我在358个节点里面遍历,也就是在非常复杂的html结构(并且这个html结构是持续变多的,因为节点是慢慢增多的)中,多次通过document.getElementById来寻找这个html结构里面的一个html对象,就造成了这个性能瓶颈,因为document.getElementById也是要遍历整个html文档的节点,再通过id的匹配来找的。那么这样一下来,在这种环境下就造成了性能问题。
也许当时作者为了面向对象的封装性而忽视了这个性能瓶颈。
一下午就这样过去了,看来作者当时的设计导致我不可能去优化这棵树,我得自己去写一个,
具体思路如下:
就是当后台传给一个xml的时候,我解析xml,将所有节点的所对应的html叠加起来设置好,再一起加载到父节点中,从而避免上面的做法。ok简单设计了一下,我的想法应该可行,明天我会接着将自己的树的思路写出来。
今天学习总结:
1.WebFXLoadTree不适合用于每次装载数据量超过100的情况,也希望大家有遇到我这样需求的时候好好考虑。
(未完待续)希望大家能给我更多好的建议,此上只是我个人的一些理解,有不当之处希望大家指出。