- 浏览: 961372 次
- 性别:
- 来自: 上海
文章分类
最新评论
-
sscsacdsadcsd:
mike8625 写道react还要自己的一些标签 还得编译 ...
对于React体系的一点想法 -
mike8625:
说的都是给大公司听的,国内很多还是小公司,做个小项目, 说实话 ...
关于国内前端和JS技术发展的乱想 -
mike8625:
react还要自己的一些标签 还得编译 编译吧浏览器端说还慢 ...
对于React体系的一点想法 -
u012814086:
下意识想到了Golang
JavaScript语句后应该加分号么? -
xueduanyang:
我是水羊,年轻的时候觉得只要有好斧子就能做成好产品,各种产品都 ...
关于国内前端和JS技术发展的乱想
JS优化已经讨论了很多了,最近又看到aimingoo的一篇。大体上,aimingoo的说法都是非常正确的。
除了像aimingoo做个案研究外,这里我想从更一般的角度总结在浏览器编程中JS优化的几个原则。
首先,与其他语言不同,JS的效率很大程度是取决于JS engine的效率。除了引擎实现的优劣外,引擎自己也会为一些特殊的代码模式采取一些优化的策略。例如FF、Opera和Safari的JS引擎,都对字符串的拼接运算(+)做了特别优化。显然,要获得最大效率,就必须要了解引擎的脾气,尽量迎合引擎的口味。所以对于不同的引擎,所作的优化极有可能是背道而驰的。
而如果做跨浏览器的web编程,则最大的问题是在于IE6(JScript 5.6)!因为在不打hotfix的情况下,JScript引擎的垃圾回收的bug,会导致其在真实应用中的performance跟其他浏览器根本不在一个数量级上。因此在这种场合做优化,实际上就是为JScript做优化!
所以第一原则就是只需要为IE6(未打补丁的JScript 5.6或更早版本)做优化!
如果你的程序已经优化到在IE6下可以接受的性能,那基本上在其他浏览器上性能就完全没有问题。
因此,注意我下面讲的许多问题在其他引擎上可能完全不同,例如在循环中进行字符串拼接,通常认为需要用Array.join的方式,但是由于SpiderMonkey等引擎对字符串的“+”运算做了优化,结果使用Array.join的效率反而不如直接用“+”!但是如果考虑IE6,则其他浏览器上的这种效率的差别根本不值一提。
JS优化与其他语言的优化也仍然有相同之处。比如说,不要一上来就急吼吼的做优化,那样毫无意义。优化的关键,仍然是要把精力放在最关键的地方,也就是瓶颈上。一般来说,瓶颈总是出现在大规模循环的地方。这倒不是说循环本身有性能问题,而是循环会迅速放大可能存在的性能问题。
所以第二原则就是以大规模循环体为最主要优化对象。
以下的优化原则,只在大规模循环中才有意义,在循环体之外做此类优化基本上是没有意义的。
目前绝大多数JS引擎都是解释执行的,而解释执行的情况下,在所有操作中,函数调用的效率是较低的。此外,过深的prototype继承链或者多级引用也会降低效率。JScript中,10级引用的开销大体是一次空函数调用开销的1/2。这两者的开销都远远大于简单操作(如四则运算)。
所以第三原则就是尽量避免过多的引用层级和不必要的多次方法调用。
特别要注意的是,有些情况下看似是属性访问,实际上是方法调用。例如所有DOM的属性,实际上都是方法。在遍历一个NodeList的时候,循环条件对于nodes.length的访问,看似属性读取,实际上是等价于函数调用的。而且IE DOM的实现上,childNodes.length每次是要通过内部遍历重新计数的。(My god,但是这是真的!因为我测过,childNodes.length的访问时间与childNodes.length的值成正比!)这非常耗费。所以预先把nodes.length保存到js变量,当然可以提高遍历的性能。
同样是函数调用,用户自定义函数的效率又远远低于语言内建函数,因为后者是对引擎本地方法的包装,而引擎通常是c,c++,java写的。进一步,同样的功能,语言内建构造的开销通常又比内建函数调用要效率高,因为前者在JS代码的parse阶段就可以确定和优化。
所以第四原则就是尽量使用语言本身的构造和内建函数。
这里有一个例子是高性能的String.format方法。String.format传统的实现方式是用String.replace(regex, func),在pattern包含n个占位符(包括重复的)时,自定义函数func就被调用n次。而这个高性能实现中,每次format调用所作的只是一次Array.join然后一次String.replace(regex, string)的操作,两者都是引擎内建方法,而不会有任何自定义函数调用。两次内建方法调用和n次的自定义方法调用,这就是性能上的差别。
同样是内建特性,性能上也还是有差别的。例如在JScript中对于arguments的访问性能就很差,几乎赶上一次函数调用了。因此如果一个可变参数的简单函数成为性能瓶颈的时候,可以将其内部做一些改变,不要访问arguments,而是通过对参数的显式判断来处理。
比如:
这个sum通常调用的时候个数是较少的,我们希望改进它在参数较少时的性能。如果改成:
其实并不会有多少提高,但是如果改成:
就会提高很多(至少快1倍)。
最后是第五原则,也往往是真实应用中最重要的性能障碍,那就是尽量减少不必要的对象创建。
本身创建对象是有一定的代价的,但是这个代价其实并不大。最根本的问题是由于JScript愚蠢之极的垃圾回收调度算法,导致随着对象个数的增加,性能严重下降(据微软的人自己说复杂度是O(n^2))。
比如我们常见的字符串拼接问题,经过我的测试验证,单纯的多次创建字符串对象其实根本不是性能差的原因。要命的是在对象创建期间的无谓的垃圾回收的开销。而Array.join的方式,不会创建中间字符串对象,因此就减少了那该死的垃圾回收的开销。
因此,如果我们能把大规模对象创建转化为单一语句,则其性能会得到极大的提高!例如通过构造代码然后eval——实际上PIES项目中正在根据这个想法来做一个专门的大规模对象产生器……
好了上面就是偶总结的JS优化五大原则。
除了这些原则以外,还有一些特殊情况,如DOM的遍历,以后有时间再做讨论。
恩..偶也是这样认为...
还很卡...内存被占用了好大..
这样说的话,childNodes是不是相当于LinkedList?
除了像aimingoo做个案研究外,这里我想从更一般的角度总结在浏览器编程中JS优化的几个原则。
首先,与其他语言不同,JS的效率很大程度是取决于JS engine的效率。除了引擎实现的优劣外,引擎自己也会为一些特殊的代码模式采取一些优化的策略。例如FF、Opera和Safari的JS引擎,都对字符串的拼接运算(+)做了特别优化。显然,要获得最大效率,就必须要了解引擎的脾气,尽量迎合引擎的口味。所以对于不同的引擎,所作的优化极有可能是背道而驰的。
而如果做跨浏览器的web编程,则最大的问题是在于IE6(JScript 5.6)!因为在不打hotfix的情况下,JScript引擎的垃圾回收的bug,会导致其在真实应用中的performance跟其他浏览器根本不在一个数量级上。因此在这种场合做优化,实际上就是为JScript做优化!
所以第一原则就是只需要为IE6(未打补丁的JScript 5.6或更早版本)做优化!
如果你的程序已经优化到在IE6下可以接受的性能,那基本上在其他浏览器上性能就完全没有问题。
因此,注意我下面讲的许多问题在其他引擎上可能完全不同,例如在循环中进行字符串拼接,通常认为需要用Array.join的方式,但是由于SpiderMonkey等引擎对字符串的“+”运算做了优化,结果使用Array.join的效率反而不如直接用“+”!但是如果考虑IE6,则其他浏览器上的这种效率的差别根本不值一提。
JS优化与其他语言的优化也仍然有相同之处。比如说,不要一上来就急吼吼的做优化,那样毫无意义。优化的关键,仍然是要把精力放在最关键的地方,也就是瓶颈上。一般来说,瓶颈总是出现在大规模循环的地方。这倒不是说循环本身有性能问题,而是循环会迅速放大可能存在的性能问题。
所以第二原则就是以大规模循环体为最主要优化对象。
以下的优化原则,只在大规模循环中才有意义,在循环体之外做此类优化基本上是没有意义的。
目前绝大多数JS引擎都是解释执行的,而解释执行的情况下,在所有操作中,函数调用的效率是较低的。此外,过深的prototype继承链或者多级引用也会降低效率。JScript中,10级引用的开销大体是一次空函数调用开销的1/2。这两者的开销都远远大于简单操作(如四则运算)。
所以第三原则就是尽量避免过多的引用层级和不必要的多次方法调用。
特别要注意的是,有些情况下看似是属性访问,实际上是方法调用。例如所有DOM的属性,实际上都是方法。在遍历一个NodeList的时候,循环条件对于nodes.length的访问,看似属性读取,实际上是等价于函数调用的。而且IE DOM的实现上,childNodes.length每次是要通过内部遍历重新计数的。(My god,但是这是真的!因为我测过,childNodes.length的访问时间与childNodes.length的值成正比!)这非常耗费。所以预先把nodes.length保存到js变量,当然可以提高遍历的性能。
同样是函数调用,用户自定义函数的效率又远远低于语言内建函数,因为后者是对引擎本地方法的包装,而引擎通常是c,c++,java写的。进一步,同样的功能,语言内建构造的开销通常又比内建函数调用要效率高,因为前者在JS代码的parse阶段就可以确定和优化。
所以第四原则就是尽量使用语言本身的构造和内建函数。
这里有一个例子是高性能的String.format方法。String.format传统的实现方式是用String.replace(regex, func),在pattern包含n个占位符(包括重复的)时,自定义函数func就被调用n次。而这个高性能实现中,每次format调用所作的只是一次Array.join然后一次String.replace(regex, string)的操作,两者都是引擎内建方法,而不会有任何自定义函数调用。两次内建方法调用和n次的自定义方法调用,这就是性能上的差别。
同样是内建特性,性能上也还是有差别的。例如在JScript中对于arguments的访问性能就很差,几乎赶上一次函数调用了。因此如果一个可变参数的简单函数成为性能瓶颈的时候,可以将其内部做一些改变,不要访问arguments,而是通过对参数的显式判断来处理。
比如:
function sum() { var r = 0; for (var i = 0; i < arguments.length; i++) { r += arguments[i]; } return r; }
这个sum通常调用的时候个数是较少的,我们希望改进它在参数较少时的性能。如果改成:
function sum() { switch (arguments.length) { case 1: return arguments[0]; case 2: return arguments[0] + arguments[1]; case 3: return arguments[0] + arguments[1] + arguments[2]; case 4: return arguments[0] + arguments[1] + arguments[2] + arguments[3]; default: var r = 0; for (var i = 0; i < arguments.length; i++) { r += arguments[i]; } return r; } }
其实并不会有多少提高,但是如果改成:
function sum(a, b, c, d, e, f, g) { var r = a ? b ? c ? d ? e ? f ? a + b + c + d + e + f : a + b + c + d + e : a + b + c + d : a + b + c : a + b : a : 0; if (g === undefined) return r; for (var i = 6; i < arguments.length; i++) { r += arguments[i]; } return r; }
就会提高很多(至少快1倍)。
最后是第五原则,也往往是真实应用中最重要的性能障碍,那就是尽量减少不必要的对象创建。
本身创建对象是有一定的代价的,但是这个代价其实并不大。最根本的问题是由于JScript愚蠢之极的垃圾回收调度算法,导致随着对象个数的增加,性能严重下降(据微软的人自己说复杂度是O(n^2))。
比如我们常见的字符串拼接问题,经过我的测试验证,单纯的多次创建字符串对象其实根本不是性能差的原因。要命的是在对象创建期间的无谓的垃圾回收的开销。而Array.join的方式,不会创建中间字符串对象,因此就减少了那该死的垃圾回收的开销。
因此,如果我们能把大规模对象创建转化为单一语句,则其性能会得到极大的提高!例如通过构造代码然后eval——实际上PIES项目中正在根据这个想法来做一个专门的大规模对象产生器……
好了上面就是偶总结的JS优化五大原则。
除了这些原则以外,还有一些特殊情况,如DOM的遍历,以后有时间再做讨论。
评论
16 楼
protti
2008-01-15
精辟的见解
请允许我收藏一下做参考用。
请允许我收藏一下做参考用。
15 楼
liudaoru
2007-11-28
呵呵,脚本就是脚本,只应该做它应该做的,现在是什么都想模拟服务器端的做法,结果搞得特别乱。
14 楼
xieye
2007-11-26
那ext是怎么做出来的呢?
13 楼
瞬间爱情
2007-11-25
afcn0 写道
垃圾回收是大问题,ie7虽然说没有内存泄露的js bug,但是实际当中还是能发现ie占用内存越来越大,必须关闭所有窗口,再打开一个新的ie内存才下来,当然ff也是,所以说浏览器压根就不是一个很好的平台,我是这么认为的,所有的js开发必须限制在一个度上,不能过于复杂,复杂其实就是不能很好理解需求的表现,任何好的实现应该都是简单的,非常容易明白的,不容易出问题的
恩..偶也是这样认为...
还很卡...内存被占用了好大..
12 楼
halfmile
2007-11-08
因为prototype为基础的语言中查找对象的属性是字符串比对,所以耗时,因此建议尽量使用:
1. Javascript 压缩器,比如 dojo shrinksafe, YUI compressor
2. 多用私有方法 http://www.crockford.com/javascript/private.html, 因为他们可以被压缩。
1. Javascript 压缩器,比如 dojo shrinksafe, YUI compressor
2. 多用私有方法 http://www.crockford.com/javascript/private.html, 因为他们可以被压缩。
xyh 写道
JS对象的垃圾回收是个问题
11 楼
longrm
2007-11-01
kaki 写道
IE7的用户群很少,对企业用户来说不推荐,因为他们需要兼容老项目,老项目不一定支持!
在当今的环境下,主要还是ie6拉,当然考虑到几年后,ie7或许会成为主流
10 楼
kaki
2007-10-25
IE7的用户群很少,对企业用户来说不推荐,因为他们需要兼容老项目,老项目不一定支持!
9 楼
hax
2007-10-07
只要不出现memory leak,占用内存多并不说明问题。
有两个例子。
第一个例子,Windows系统启动后你就会发现会逐渐占用大量内存,空闲的物理内存通常很少。但是这并不是说明Windows就不好,而是因为它采取不同的内存使用策略(就是尽可能的利用物理内存,比如用作缓存)。
第二个例子,是Java程序,通常jvm也会占据很多内存而很少会释放,这是其垃圾回收策略决定的,并不表示其就不好。
所以以占用内存多来判断浏览器不是好的平台,是站不住脚的。
当然IE7,甚至FF,肯定还是存在某些内存泄露的情况。
有两个例子。
第一个例子,Windows系统启动后你就会发现会逐渐占用大量内存,空闲的物理内存通常很少。但是这并不是说明Windows就不好,而是因为它采取不同的内存使用策略(就是尽可能的利用物理内存,比如用作缓存)。
第二个例子,是Java程序,通常jvm也会占据很多内存而很少会释放,这是其垃圾回收策略决定的,并不表示其就不好。
所以以占用内存多来判断浏览器不是好的平台,是站不住脚的。
当然IE7,甚至FF,肯定还是存在某些内存泄露的情况。
8 楼
afcn0
2007-10-07
垃圾回收是大问题,ie7虽然说没有内存泄露的js bug,但是实际当中还是能发现ie占用内存越来越大,必须关闭所有窗口,再打开一个新的ie内存才下来,当然ff也是,所以说浏览器压根就不是一个很好的平台,我是这么认为的,所有的js开发必须限制在一个度上,不能过于复杂,复杂其实就是不能很好理解需求的表现,任何好的实现应该都是简单的,非常容易明白的,不容易出问题的
7 楼
hax
2007-10-06
我正在修订本文,会加入闭包的部分。
6 楼
xyh
2007-10-05
JS 的闭包是个问题,
垃圾回收也是个问题。
学习中......
垃圾回收也是个问题。
学习中......
5 楼
xyh
2007-10-05
JS对象的垃圾回收是个问题
4 楼
ak_2005
2007-09-27
学习了!
3 楼
i_love_sc
2007-09-26
hax 写道
关于DOM遍历的补充:
如前所述,IE6 DOM中childNodes.length每次都是要遍历所有节点统计个数得出的。而childNodes[i]的访问,也要遍历直到第i个元素。所以在子节点数量巨大的情况下(超过1000),不宜使用for循环来遍历childNodes,否则会死得很惨。而应使用这样的遍历方法:
另一个方式是使用IE自己的DHTML集合属性elem.children,但是它与childNodes不同,不包含文本节点。
如前所述,IE6 DOM中childNodes.length每次都是要遍历所有节点统计个数得出的。而childNodes[i]的访问,也要遍历直到第i个元素。所以在子节点数量巨大的情况下(超过1000),不宜使用for循环来遍历childNodes,否则会死得很惨。而应使用这样的遍历方法:
var node = elem.firstChild; while (node != null) { ... node = node.nextSibling; }
另一个方式是使用IE自己的DHTML集合属性elem.children,但是它与childNodes不同,不包含文本节点。
这样说的话,childNodes是不是相当于LinkedList?
2 楼
笨笨狗
2007-09-26
dom元素遍历的确是个头大的问题,回头把我那树菜单的遍历处理按楼主的方式改写一下试试,非常感谢:)
1 楼
hax
2007-09-26
关于DOM遍历的补充:
如前所述,IE6 DOM中childNodes.length每次都是要遍历所有节点统计个数得出的。而childNodes[i]的访问,也要遍历直到第i个元素。所以在子节点数量巨大的情况下(超过1000),不宜使用for循环来遍历childNodes,否则会死得很惨。而应使用这样的遍历方法:
另一个方式是使用IE自己的DHTML集合属性elem.children,但是它与childNodes不同,不包含文本节点。
如前所述,IE6 DOM中childNodes.length每次都是要遍历所有节点统计个数得出的。而childNodes[i]的访问,也要遍历直到第i个元素。所以在子节点数量巨大的情况下(超过1000),不宜使用for循环来遍历childNodes,否则会死得很惨。而应使用这样的遍历方法:
var node = elem.firstChild; while (node != null) { ... node = node.nextSibling; }
另一个方式是使用IE自己的DHTML集合属性elem.children,但是它与childNodes不同,不包含文本节点。
发表评论
-
论ES6模块系统的静态解析
2013-03-14 04:56 15876本文是Dave Herman的《Stati ... -
如何创建一个JavaScript裸对象
2012-08-27 02:11 8050所谓裸对象,即 naked object ,是指没有原型(sp ... -
JavaScript语句后应该加分号么?
2012-06-19 03:10 14380这是一个老生常谈的问 ... -
shim是应该抛异常还是应该fail silently?
2011-08-11 17:26 5581玉伯发布了es5-safe模块 ... -
7月30日的广州演讲视频和Slides
2011-08-01 23:38 31757月30日在W3CTech广州站活动上的演讲,题目是:ECMA ... -
如何判断一个函数的意图是被用作构造器,也就是可视为“类”
2011-07-21 13:55 2948前提是不要求做什么特殊标记。只是最大可能的猜测函数的作用大概是 ... -
关于国内前端和JS技术发展的乱想
2011-07-19 18:53 33267玉伯在我的一条微博后面写了一些(和主题不是很相关但)非常值得思 ... -
Module与Trait的比较
2011-08-12 12:50 4004最近我多次提及module和trait。 粗看,我们可以发现 ... -
如何将let结构(block scope)转换到当前的JavaScript代码
2011-07-12 17:24 3009本文是对如何将let结构转换到ES3代码的补充。 首先,原文 ... -
JavaScript的未来方向之观察
2011-07-12 02:53 8373最近每次去杭州,都有 ... -
我为什么力挺NodeJS
2011-07-04 00:27 0之前在参加CNodeJS社区在 ... -
JS之父再谈JS历史(续完)
2010-12-31 04:20 3439又到年底,我觉得是时候还债了。自开blog来,我出了不少“太监 ... -
我为什么是DC黑续,兼答Tin
2010-04-27 14:29 0我同意安全是一个重要问题。我不同意的是把所谓安全放到凌驾于其他 ... -
我为什么是DC黑─Why I disagree with Douglas Crockford
2010-04-26 17:51 11016参加完了QCon北京大会, ... -
写对正则:一行代码,速度差50倍
2009-05-12 03:43 60132009-05-11 A lesson of ... -
JavaScript的EOS(分号)问题
2009-05-08 16:24 5779在http://bbs.51js.com/viewthre ... -
JavaScript五大关键字
2009-05-06 17:53 4768近期做语法高亮项目的副产品,是统计了一下几个主流JS工具包中各 ... -
curry和partial的差别
2009-03-28 00:15 371451js上asfman翻译了http://ejohn.org/ ... -
Eval is Evil , With evil too
2009-03-27 18:39 0with的问题: 2009-3-27 17:12:40 ... -
IE全局变量的Dissociative Identity Disorder(人格分裂症)
2009-03-16 02:47 14737最近,小麦提出了一个疑惑: 小麦 写道最后介绍一个我也搞不明白 ...
相关推荐
JavaScript性能优化是提升网页加载速度和用户交互体验的关键。以下是一些实用的JS优化技巧: ...遵循这些优化原则,可以有效地提升JavaScript代码的执行效率,从而加快网页加载速度,提升用户体验。
在IT行业中,优化JavaScript(JS)和CSS代码对于提高网页性能和用户体验至关重要。...尽管现在有更多先进的工具(如Webpack、Babel、Prettier等),但理解这些基本优化原则仍然是每个前端开发者必备的技能。
- 在代码的后期维护和优化阶段,可以考虑重构以遵循单一职责原则。 其次,**开放封闭原则**(Open-Closed Principle, OCP)主张已定义的对象或函数应允许扩展,但禁止修改。其核心思想是通过增加新代码来扩展功能,...
网站优化是一个很大的话题,有一些通用的原则,也有针对不同开发平台的一些建议。雅虎的工程师团队曾经给出过 35 个最佳实践,可以参照Best Practices for Speeding Up Your Web Site。同时,他们还发布了一个相应的...
Vue.js 是一款非常流行的前端JavaScript框架,以其轻量级、易学易用和高性能的特点深受开发者喜爱。在项目开发过程中,优化Vue.js的结构对于提高应用性能和减少资源占用至关重要。"vue_vue_"这个标题可能指的是针对...
JavaScript代码优化是一项持续且重要的工作,它有助于提高代码的执行效率、可读性和可维护性。...随着现代JavaScript框架和构建工具的发展,遵循这些优化原则变得更加容易,开发者应当在实践中积极应用这些知识。
--形成关键词分析报告及布署方案 搜索引擎友好化---撰写站点修改措施建议书 内容强化---资讯频道建立、对编辑团队的培训 内部优化---URL优化、各级页面DIV重构、关键字布局、目录逻辑结构调整、JS优化、专题页建设等...
综上所述,提高JavaScript的性能,关键在于理解其代码的执行机制,以及合理利用各种JavaScript引擎提供的优化技术。开发者应该在整个开发周期中持续关注性能问题,采用合适的工具和方法来诊断和解决性能瓶颈,并且...
"基于CSS和JavaScript的网页选项卡的设计和优化" 根据提供的文件信息,我们可以...基于CSS和JavaScript的网页选项卡的设计和优化需要遵循设计原则,简短、精炼、整体性等,才能使选项卡在实际应用中发挥最佳的效果。
它的设计原则是简洁、直观,使得页面在微信内置浏览器中运行时,能保持与微信自身界面的一致性,提升用户的使用感受。 4. **JavaScript 开发语言**: JavaScript 是一种广泛应用于网页和网络应用的脚本语言,它在...
Chrome V8引擎中的JavaScript数组实现分析与性能优化 在本文中,我们将对Chrome V8引擎中的JavaScript数组实现进行深入分析,并探讨如何通过优化JavaScript数组的使用方式来提高程序效率。在实际应用中,JavaScript...
这个文件是MUI框架的完整源代码,包含了所有未经过压缩和优化的JavaScript代码。开发者在开发阶段通常会使用这个版本,因为其中包含了详细的注释和调试信息,方便在开发过程中进行问题排查和功能调试。MUI.js提供了...
"web+笔试+面试汇总+前端优化总结+js+css"的主题涵盖了前端开发中的关键领域,包括ECMAScript语法、HTML表格与表单处理、浏览器对象模型(BOM)、事件处理以及前端优化策略。 ECMAScript是JavaScript的标准化规范,...
4. 性能优化:对于大数据量的图表,要考虑性能优化,比如使用虚拟化技术减少渲染元素的数量。 综上所述,JavaScript提供了许多优秀的库来帮助开发者创建统计图和报表,选择哪种库主要取决于项目需求、开发者经验和...
本文主要探讨了如何在遵循性能优化原则的同时,兼顾前端工程的高效管理,通过实例解析了百度前端集成解决方案小组(F.I.S)在打造高性能前端架构过程中所采取的技术策略。 雅虎14条性能优化原则是前端性能优化的...
性能优化是提升软件系统效率的关键环节,涉及到多个层面的调整和改进。...每个环节的优化都需要根据实际情况和需求进行,同时,要遵循“有理想而不理想化”的原则,以务实的态度寻求最适合的优化方案。
这个名为"js.rar_javascript_js_js 农历_lunar"的压缩包包含了一个专门处理中国农历的JavaScript实例。在这个实例中,开发者仅用了一个文件就实现了农历的计算和展示功能,展现了JavaScript的强大灵活性和高效性。 ...