decodeURIComponent导致的性能问题

文章讲述了作者在处理大量数据动态加载时遇到的性能问题。最初认为是innerHTML的问题,但通过测试发现,真正的原因是使用了decodeURIComponent进行解码操作,这在处理大量编码时极其耗时。将解码操作移至后台并优化后,性能得到了显著提升,解决了页面加载缓慢的问题。
摘要由CSDN通过智能技术生成

       近两个月,我似乎总在和性能问题打交到。当页面动态展现几千个节点时,又出现了性能问题。

       这是个编码比对的功能,省工商局可以选择总局的某一个标准编码类型,系统自动将该类型下的所有编码全部列出,为了增强效果,不允许刷新页面,所有编码项信息以checkbox的形式动态添加。
在几个月前我就完成了这部分功能,加入了页面级的映射校验和映射关系动态添加/删除,我一直以为每
个编码类型下至多有几十个编码,我的测试也一直用的是自己添加的20个编码项。直到今天,客户不太熟练的操作着鼠标,不慌不忙地选中了“行政区划”一项,于是——死机了。

       没有什么比在演示现场出现死机问题更令人尴尬,这也毫无悬念地遭到了领导们的强烈谴责,这段程序的作者也自然脸上无光。

       我一直认为所有的性能问题都有办法解决,第一个念头是大批量的数据展示导致了速度缓慢,那个innerHTML大概没有传说中的那么好用,虽然过去它一直是个好兄弟。但是事实又一次证明,我的第一直觉通常是站不住脚的,问题不在这里。

       在动态加载时触发了下面的代码片段: 

try
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值