We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
参考:
吹毛求疵的追求优雅高性能JavaScript
switch...case和if...else效率比较
浏览器的工作原理:新式网络浏览器幕后揭秘
因为用控制台是测不出性能的,因为控制台本质上是个套了一大堆安全机制的eval,它的沙盒化程度很高。如:
for (var i = 1; i <= 10; i++) { console.time(i); for (var j = 0; j <256*256*256; j++) { }; console.timeEnd(i); } // spend time: 40~45ms(the old version chrome will spend about 4000ms) function simpleEval() { eval("for (var i = 1; i <= 10; i++) { \ console.time(i); \ for (var j = 0; j <256*256*256; j++) { }; \ console.timeEnd(i); \ }") } simpleEval(); // spend time: 6407~6825ms function insideEval() { (0,eval)("for (var i = 1; i <= 10; i++) { \ console.time(i); \ for (var j = 0; j <256*256*256; j++) { }; \ console.timeEnd(i); \ }") } insideEval(); // spend time: 40~43ms function insideFunction() { for (var i = 1; i <= 10; i++) { console.time(i); for (var j = 0; j <256*256*256; j++) { }; console.timeEnd(i); } } insideFunction(); // spend time: 15~22ms
console.time(label) & console.timeEnd(label) console.time()启动一个具有关联标签的新计时器。使用相同标签调用 console.timeEnd() 时,定时器将停止,经过的时间将显示在控制台中。计时器值精确到亚毫秒。传递到 time() 和 timeEnd() 的字符串必须匹配,否则计时器不会结束。
label
console.time()
console.timeEnd()
time()
timeEnd()
console.trace() 从调用此方法输出一个堆栈跟踪。
下面是几张在Chrome环境下进行内存测试的结果:
可以看出:
上述操作都在结尾销毁了框架,这些方法如下:
// 初始化框架的API var editor = UE.getEditor("communicake_content", {}); editor.addListener('focus', function(event) {}); editor.addListener('keyup', function(event) {}); // 解除事件绑定的API editor.removeListener('focus'); editor.removeListener('keyup'); UE.delEditor('communicake_content');
基本都是解析->构建DOM树->绘制。
解析->构建DOM树->绘制
webkit解析主流程。
Gecko解析主流程
所有的常规解析器都不适用于 HTML(我并不是开玩笑,它们可以用于解析 CSS 和 JavaScript)。HTML 并不能很容易地用解析器所需的与上下文无关的语法来定义。
有一种可以定义 HTML 的正规格式:DTD(Document Type Definition,文档类型定义),但它不是与上下文无关的语法。
这初看起来很奇怪:HTML 和 XML 非常相似。有很多 XML 解析器可以使用。HTML 存在一个 XML 变体 (XHTML),那么有什么大的区别呢?
区别在于 HTML 的处理更为**“宽容”**,它允许您省略某些隐式添加的标记,有时还能省略一些起始或者结束标记等等。和 XML 严格的语法不同,HTML 整体来看是一种“软性”的语法。
显然,这种看上去细微的差别实际上却带来了巨大的影响。一方面,这是 HTML 如此流行的原因:它能包容您的错误,简化网络开发。另一方面,这使得它很难编写正式的语法。概括地说,HTML 无法很容易地通过常规解析器解析(因为它的语法不是与上下文无关的语法),也无法通过 XML 解析器来解析。
document.write
The text was updated successfully, but these errors were encountered:
No branches or pull requests
优化
参考:
吹毛求疵的追求优雅高性能JavaScript
switch...case和if...else效率比较
浏览器的工作原理:新式网络浏览器幕后揭秘
测试前言
不在控制台测试
因为用控制台是测不出性能的,因为控制台本质上是个套了一大堆安全机制的eval,它的沙盒化程度很高。如:
有用的console
console.time(
label
) & console.timeEnd(label
)console.time()
启动一个具有关联标签的新计时器。使用相同标签调用console.timeEnd()
时,定时器将停止,经过的时间将显示在控制台中。计时器值精确到亚毫秒。传递到time()
和timeEnd()
的字符串必须匹配,否则计时器不会结束。console.trace()
从调用此方法输出一个堆栈跟踪。
示例: ueditor框架内存占用的分析
下面是几张在Chrome环境下进行内存测试的结果:
可以看出:
上述操作都在结尾销毁了框架,这些方法如下:
基础知识
浏览器的主要组件
浏览器的解析过程
基本都是
解析->构建DOM树->绘制
。webkit解析主流程。
Gecko解析主流程
HTML
所有的常规解析器都不适用于 HTML(我并不是开玩笑,它们可以用于解析 CSS 和 JavaScript)。HTML 并不能很容易地用解析器所需的与上下文无关的语法来定义。
有一种可以定义 HTML 的正规格式:DTD(Document Type Definition,文档类型定义),但它不是与上下文无关的语法。
这初看起来很奇怪:HTML 和 XML 非常相似。有很多 XML 解析器可以使用。HTML 存在一个 XML 变体 (XHTML),那么有什么大的区别呢?
区别在于 HTML 的处理更为**“宽容”**,它允许您省略某些隐式添加的标记,有时还能省略一些起始或者结束标记等等。和 XML 严格的语法不同,HTML 整体来看是一种“软性”的语法。
显然,这种看上去细微的差别实际上却带来了巨大的影响。一方面,这是 HTML 如此流行的原因:它能包容您的错误,简化网络开发。另一方面,这使得它很难编写正式的语法。概括地说,HTML 无法很容易地通过常规解析器解析(因为它的语法不是与上下文无关的语法),也无法通过 XML 解析器来解析。
document.write
,就会添加额外的标记,这样解析过程实际上就更改了输入内容。The text was updated successfully, but these errors were encountered: