前后端coffeescript解析效率测试
发布于 8个月前 作者 think2011 823 次浏览

概述

  • 觉得总是引用编译后的coffeescript很麻烦,而且文件有些累赘。
  • 所以打算直接引用coffeescript试试。
  • 这是一个简单的测试,目的是衡量选择效率还是选择时间。

测试代码(节选)

前端

for (var i = 0; i <= 10000000; i++) {}
document.write('前端javascript运行时间:' + (Date.now() - window.timestamp) + '毫秒');
i = 0
while i <= 10000000
    i++
document.write "前端coffeescript运行时间:#{(Date.now() - window.timestamp)}毫秒"

后端

var http = require('http');

http.createServer(function (req, res) {
    var timestamp = Date.now();
    for (var i = 0; i <= 10000000; i++) {}
    res.end('后端javascript运行时间:' + (Date.now() - timestamp) + '毫秒');
}).listen(3000);
http = require "http"

http.createServer((req, res) ->
  timestamp = Date.now()
  i = 0
  while i <= 10000000
    i++
  res.end "后端coffeescript运行时间:#{(Date.now() - timestamp)}毫秒"
).listen 3000

结果

  • 虽然这是一个不严谨的测试,但结果也能说明,在前端引用 coffee-script.js 是不明智的。
  • 但出乎意料的是,后端的 coffeescript 居然比原生的还快?? Σ( ° △ °|||)︴
  • 希望懂专业测试的朋友能够验证一下上一条的结论。

总结

  • coffeescript真心好用,既然前端麻烦一些,但我也还是很愿意用的!
  • 之前以为会难于在原生和coffeescript之间切换思维,现在看来是多虑了,我能够很顺畅的转换两种语法思维。:D

技术: javascript & coffeescript
时间: 2014年6月
博客: think2011
15 回复

用coffee多久鸟?

关于lz概述的第一点。why not use grunt

@hzbqjltx 我一直不明白该怎么用grunt才合适。 我目前是用webstorm,每次保存coffee的时候,会自动编译,当前目录会出现 .coffee .map .js 三个文件,觉得难管理,能告诉我大概的管理思路吗?

@think2011 实际项目中用这货?

grunt 直接把coffee打包编译了后 发到线上 ,线上直接引用js文件。

@ql9075 是在开发过程中,觉得一个目录下多出2个额外文件感觉多余和不方便查看管理。

@think2011 不用看编译后的js啊,grunt watch 直接监视你的coffee改动,修改后直接提交就行。

@think2011 使用grunt管理你的项目任务。其中一个可以是,将源码与运行文件分离。可以建立一个bin或者build的文件。放运行文件。将源码目录结构都映射到这个运行文件夹里面

这个测试有点问题啊, CoffeeScript 执行的时候, 是先编译一遍到 JS, 然后执行, 按楼主测试的代码逻辑, 等于是 (N 遍 JS 的 for) 对比 (N 遍 JS 的 while + 一次编译)… 如果说后者快, 只能说明 whilefor 快… 这个事情好像确实有?..

管理 CoffeeScript 编译代码的话, 放在同一个目录不明智. 区分开两个目录比较合理:

coffee -o build/ -wc src/

至于用什么编译, Grunt Gulp 命令行都随便了

@hzbqjltx 映射是指通过 cmd中的mklink方法映射相同的文件,还是说,一个文件夹放源码,一个文件夹放上线文件?

@think2011 不是,你看下grunt的教程。这些任务都可以定制为自动化的过程。

两者不能这么测试地比吧

回到顶部