十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
js代码执行速度 很大程度上依赖浏览器的引擎 不同浏览器跑 速度可能会差很多
成都创新互联坚持“要么做到,要么别承诺”的工作理念,服务领域包括:网站设计、成都网站建设、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的行唐网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!
然后就是算法的时间复杂度 和处理的数据量
还有就是多次操作dom也相当耗时
你要分析下你的代码慢的原因
是循环套循环了?
还是说逻辑太复杂了
如果多次操作dom 导致页面reflow次数过多
渲染次数过多 也可能给你感觉很慢
1.后台统计方法执行时间,显示为秒级别longstartTime=System.currentTimeMillis();//执行方法longendTime=System.currentTimeMillis();floatexcTime=(float)(endTime-startTime)/1000;System.out.println("执行时间:"+excTime+"s");2.前台统计时间,显示为秒级别varst=newDate();//执行方法varet=newDate();varexecTime=(et-st)/1000;varet=document.getElementById("time");et.innerHTML="执行时间:"+execTime+"s";不过从Firefox的firebug调试工具统计时间来看,前台统计时间比真实时间短,调试工具统计的时间跟后台统计的时间相近,且稍长,合情理,所以前台统计数据直接从后台取。3.得出查询速度的方法是:在各个select语句前加:declare@ddatetimeset@d=getdate()并在select语句后加:select[语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())
建议你观察下页面内资源的加载时间,同时在页面中打开多个js文件主要耗时为TTFB,主要耗时为「等待某个js加载渲染完成」+「等待dns解析时间」+「浏览器的pending策略」等。你在页面内同步加载了多个js资源,所以下载速度的不可控是正常的。
因为JS在执行的时候会影响到页面的DOM和样式等情况。浏览器在解析渲染HTML的时候,如果解析到需要下载文件的script标签,那么会停止解析接下来的HTML,然后下载外链JS文件并执行。减少 JavaScript 对性能的影响有以下几种方法:1、将所有的
方案1:针对支持html5 webworker的现代浏览器方案:。
代码1.你的大量计算,放到一个js文件中。如下:
//job.js
onmessage =function (evt){
//do massive job.在这里你进行大量耗时的计算过程。
postMessage( data );//将计算结果的数据发送会主线程
}
你的页面代码:
!DOCTYPE HTML
html
head
meta http-equiv="Content-Type" content="text/html; charset=utf-8"/
script type="text/javascript"
//WEB页主线程
var worker =new Worker("job.js"); //创建一个Worker对象并向它传递将在新线程中执行的脚本的URL
worker.postMessage('开始计算');
worker.onmessage =function(evt){//接收worker传过来的数据函数
console.log(evt.data);//输出worker发送来的数据,这里就获取到了大量计算的结果。
}
/script
/head
body/body
/html
方案2:对于不支持WebWorker线程的浏览器。
可以考虑分批处理。即是说创造一个间隔定时器setInterval。
每隔一小段时间,处理大量数据中的一部分。
这样就可以避免大量计算导致浏览器卡死。
大致代码如下(这里是简单的例子。具体情况具体分析。):
假设我们要计算1000万个数据的和。
var jobData = [];//假设是一个数组。里面有1000万个数据。
function sliceJob(){
var num = (jobData.length / 100) + 1;//把任务数据划分为100份。
var portion = 100000;//每份有10万个数字。
var addition = 0;//这里用来保存最后的结果。一开始是0;
var intv = setInterval(function(){
if(num--){
//然后每一份结果。
additoin += every;
} else {
计算最后一份,然后输出结果。
alert('最终结果是:', addition);
window.clearInterval(intv);
}
}, 50);
}
此外。jQuery的deferred对象无法实现你的要求。
因为deferred对象的目的是为了串行处理异步过程。
但是异步过程在执行的过程中,如果耗时过长,仍然会阻塞浏览器线程,导致浏览器不可操作(卡死)。
唯一的一个例外是$.ajax。$.ajax方法也会返回一个Deferred对象。但是由于该异步过程是用的XMLHttpRequest。而xhr默认是异步执行的,相当于另起一个线程,因此不会阻塞浏览器县城。
说起JS的异步执行机制,如果百度一下,你首先会发现阮一峰的写过一篇关于异步机制的文章( ),等你津津有味又一头雾水的看完,然后继续看百度的其他结果,然后会发现,阮一峰的这篇被另一个大牛朴灵给批判了
( )。
由此可见,关于异步执行机制到底是怎么回事,因为涉及到浏览器底层机制,所以不容易彻底了解清楚,就算是大牛阮一峰,也只是通过英文文献来了解,而且一知半解。我的这篇文章只是试图尽可能简单的描述一下JS的异步执行机制,坦白说,我现在并不能完全弄懂这个机制,所以也不能完全解释清这个机制,所以,如果我写的越严谨,就越容易出错,我只能简单但是较模糊的描述一下:
JS的运行环境是一个很复杂的环境,它里面有非常多的复杂的名词事物,用简单又不严谨的说法来说,运行环境里至少有下面这些事物:
有一个国外的web app,专门用来讲解异步事件的门道 Loupe ,这个更接近真实情况。为什么我不讲解这个?因为更复杂了,我们并不打算研究浏览器的底层,不是么?
然后说一下任务队列里的任务。所有任务可以分成两种,一种是同步任务(synchronous),另一种是异步任务(asynchronous)。同步任务指的是,靠主线程自己就可以执行完成的任务;异步任务指的是,主线程执行开始之后,需要靠主线程之外的线程才能完成的任务。由主线程决定是否要动用其他线程。以下内容,不再提栈,只说主线程。
现在说重点:
异步任务的执行机制是:
当主线程遇到一个异步任务,比如一个ajax请求,当主线程执行到 xhr.send() 的时候,这个send命令是立即执行的, 并不会像一些人想象的,拖到所有同步任务的最后面。 然后主线程向http线程发送指令,要求http线程向服务器发送请求。这里强调一下http线程,显然它不是主线程的一部分,因为它可以并发,如果你有100个ajax请求,每个都需要1秒钟,是不是http线程要花100秒呢?并不是,它会并发100个请求,总共耗时大约1.01秒就完成了。
主线程向以http线程为代表的几个线程发送指令之后,主线程就暂时不再管这个ajax任务了,而是去看任务队列里的下一个任务。
http线程发送了请求之后接收反馈,收到之后,形成一个新的事件(可以叫做“我收到啦!”事件),然后插入到回调函数队列中,因为回调函数队列的优先级很低,所以会排到总队列的最后面,其结果就是:主线程把同步任务都完成了,才开始执行异步事件的 回调 。 注意,并不是异步任务在全体同步任务结束之后才开始,而是异步任务的回调通常在全体同步任务结束之后才开始!异步任务跟异步任务的回调是两回事!是两个任务!一个鲜明的例子就是 setTimeout(fn, 1000) ,计时是从主线程遇到 setTimeout() 任务,然后分配给计时器线程,计时器线程开始干活的时候就开始计时了!只不过要1秒之后 fn 才执行! setTimeout() 和 fn 是两个任务! setTimeout() 是立即执行, fn 才是1秒之后执行。但是 setTimeout() 的执行,人眼是感受不到的,因为并没有什么地方有一个秒表告诉你 setTimeout() 开始执行了;而fn的执行,人眼能感受到,所以人们会错误的以为fn才是异步任务,其实fn并不是, fn 是个回调任务,往往 fn 是同步任务,比如 fn 可能是 console.log(123) ,这怎么会是异步任务。
所以,异步机制是浏览器的两个或以上常驻线程共同完成的,异步请求是JS主线程和其他某个线程共同完成的,JS的执行线程发起异步请求(这时浏览器会开一条新的HTTP请求线程来执行请求,这时JS自己的任务已完成,继续执行线程队列中剩下的其他任务),然后在未来的某一时刻"任务队列"线程监视到之前的发起的HTTP请求已完成, "任务队列"就会把完成事件插入到JS执行队列的尾部等待JS处理 。
最后专门说说定时触发(settimeout和setinterval)。
定时触发是由浏览器的定时器线程执行的定时计数, 然后在定时时间到达之后,定时器线程把定时处理函数的执行请求插入到JS回调队列的尾端。
这个1到底是100毫秒之后弹出,还是1000毫秒(或更多时间)后弹出呢?又或是1100毫秒之后弹出?
答案是,1000毫秒多一点点之后弹出。
原因:浏览器会先执行setTimeout,也就是开始计时,然后开始执行sometask,执行了1000毫秒,然后去回调队列里看回调任务,alert(1);早就恭候了,因为定时100毫秒之后alert(1)就可以执行了。所以,等1000毫秒的任务完成,1就会立即弹出,所以答案是1000毫秒多一点点之后弹出。
所以用这两个函数的时候,实际的执行时间是大于或等于指定时间的,不保证能准确定时的。
最后强调一下setInterval。比如我希望每100毫秒打印一个1。然后,又有极端情况,就是sometask耗时1000毫秒。你以为sometask结束之后会打出10个1么?并不会,只会打出1个1,因为setInterval第一次读秒结束之后,回调队列出现了一个alert(1),根据之前的理论,并不会执行。又过了100毫秒之后,计时器线程会去观察回调队列是不是已经有了alert(1),如果有,就不再往回调队列里加alert(1),目的就是为了避免回调叠加执行。
总之,你需要记住,异步任务就是主线程在任务队列里看到了这个任务,看了一眼之后就然后安排别的线程帮忙,然后主线程就忙别的去了,别的线程帮忙完事之后,再在队列末尾放一个新任务叫“帮忙完毕”,到此异步任务本身就完事。主任务看到“帮忙完毕”任务之后,就去执行回调,回调执行完,这个异步任务连同回调就全都完事。然后,如果并没有回调。。。没有就没有呗。
看得出来你不太懂 JS,先把代码给你,做了很多注释,先仔细看看,然后后面讲解为什么:
// 检查表单的函数
function checkForm() {
/** @type {string} 数据容器 */
var merArr="";
/** @type {number} 局部循环指针 */
var p=0;
/** @type {Array.Element} 获取待提交的表单元素 */
var items = document.getElementsByName("add_mer");
// 遮罩
Ext.getBody().mask("数据保存中,请稍等..."); //这里没有起作用
// 开始检查
doCheck();
function doCheck(){
/**
* 循环构造字符串
* 为了避免长时间阻塞,每一段仅允许循环 100 次
* 如果一次不能完成,则分组完成
*/
for(var i=0; i100 pitems.length; i++, p++) {
if (items[x].checked) {
merArr =merArr+Trim(items[x].value)+",";
}
}
// 如果循环结束
if (p === items.length) complete();
// 如果循环没有完成,则用 setTimeout 交出控制权,延迟循环
else setTimeout(doCheck, 1);
}
// 检查结束,真正的处理表单
function complete(){
document.getElementById("merArray").value = merArr;
if(merArr==""){
alert("请勾选!");
Ext.getBody().unmask();
return false;
}
document.forms['listForm'].action = 'addGroupMer.action';
document.forms['listForm'].submit();
}
return false;
}
下面是讲解:
1、 JS 是阻塞式的。在一个 JS 函数正在执行的时候,对 DOM 的渲染其实对于用户来说是不可见的。也就是说,你在一个 JS 循环中不论对 DOM 做了什么,用户都是看不到中间过程,只能看到一个最终的结果。
2、 所以,上面代码的核心是,把耗时特别长的操作部分,使用 setTimeout 延迟。 setTimeout 可以把控制权还给浏览器,留出足够的页面渲染时间。
3、 setTimeout 的过程中,要注意变量的处理。对于闭包的应用是一个需要注意的地方。
以上,请采纳,请给分。