jssc 4.2

http://code.google.com/p/jssc/

终于赶上了啊，在4月2号放出4.2，HOHO，这日子不错呢～

兼容sh了，使用方法见wiki：http://code.google.com/p/jssc/wiki/usage

更改了许多dom结构，还有兼容复制，还有修复了若干隐藏bug，还有加入了flex。

休息休息，累得萎靡了……

评论

9 楼 hax 2009-04-29  

测试版本：http://pies.svn.sourceforge.net/viewvc/pies/trunk/2009/tiny-parser/test2.html

测试源代码分别是base2（1600行）、jquery（4300行）和dojo（9800行）。

8 楼 hax 2009-04-27  

最近几天在忙getUsedValue，手写highlight暂停着没做。争取明天发布一个小版本，供测试一下。

7 楼 Army 2009-04-27  

今天才忙的过来测试了一下，ie、ff、chrome都试了试。

很奇怪的是，flash在这三种浏览器的运行效率居然有略微的不同，其中ff上跑完9000行代码大概是2.5秒，随机分布有时会略微低一些，比如2.4秒等；而ie和chrome都要慢一些，大概在2.7秒、2.8秒的样子。

上面只是传递到flash分析再传递回来分析结果的时间，还未加上innerHTML，假如加上，chrome就明显占了优势，大概在3.7秒左右；ff则是4.1秒左右；ie最惨，占了4.6秒。

至于js分析9000行代码能达到500ms的效率我感到很吃惊，因为之前的版本以及使用hl的结果，让我感到js的分析能力远远达不到这个要求；在flash中由于对其性能的信任，我没有用正则，直接进行的字符串遍历。有机会到要试一试正则在flash中比字符串遍历的性能到底有没有提高，提高多少。

6 楼 Army 2009-04-17  

hax 写道

建议你做一下性能测试，精确测量一下每个环节的耗费。我认为，AS理想上dojo那个完整的9000多行代码应该能在1秒钟之内搞定（假设是主流的2G主频的机器）。其中500毫秒是innerHTML。也就是说parse和传递不能大于500毫秒。因为我现在准备做js的parser生成器，目标是产生出的parser的效率能和手写parser一样高。为此，我先手写了一个js的highlighter（当然功能很简单，只有基本的highlight，而且只针对js语法）。然后再转换为用parser生成器产生，然后对比手写版本和生成的版本，最后要使得生成的版本和手写版本的效率一样高。这个手写版本还没有做完，目前只解析了comments、string literal以及分行，就这些而言，解析dojo那个9000行代码的时间（在我的T60笔记本上）是300毫秒到500毫秒，最快的Chrome只有100毫秒不到（因为Chrome的正则性能比其他浏览器高一个数量级）。要支持所有的特性，估计时间会翻几番，但是只是线性的（因为parser内的算法只需要遍历整个字符串一次）。因此假设通常的代码高亮不超过1000行，则解析时间应该不会超过300毫秒。如果确实和我预计的差不多，你是否可以考虑基于parser生成器来继续纯js版本的分支？

OK，如果真能达到这种要求的话，倒可以考虑。

http://code.google.com/p/jssc/

我更新了4.2.2，很大有了提升，加了两个class命名规则：mouse-over和fold。

http://code.google.com/p/jssc/wiki/usage

我用新的来试试9000行代码吧～

5 楼 hax 2009-04-17  

建议你做一下性能测试，精确测量一下每个环节的耗费。
我认为，AS理想上dojo那个完整的9000多行代码应该能在1秒钟之内搞定（假设是主流的2G主频的机器）。其中500毫秒是innerHTML。也就是说parse和传递不能大于500毫秒。

因为我现在准备做js的parser生成器，目标是产生出的parser的效率能和手写parser一样高。为此，我先手写了一个js的highlighter（当然功能很简单，只有基本的highlight，而且只针对js语法）。然后再转换为用parser生成器产生，然后对比手写版本和生成的版本，最后要使得生成的版本和手写版本的效率一样高。

这个手写版本还没有做完，目前只解析了comments、string literal以及分行，就这些而言，解析dojo那个9000行代码的时间（在我的T60笔记本上）是300毫秒到500毫秒，最快的Chrome只有100毫秒不到（因为Chrome的正则性能比其他浏览器高一个数量级）。要支持所有的特性，估计时间会翻几番，但是只是线性的（因为parser内的算法只需要遍历整个字符串一次）。因此假设通常的代码高亮不超过1000行，则解析时间应该不会超过300毫秒。

如果确实和我预计的差不多，你是否可以考虑基于parser生成器来继续纯js版本的分支？

4 楼 Army 2009-04-17  

hax 写道

有没有单独的parse和拼接出html字符串的性能测试？假设as的版本只比js快一点点，那么是否可以考虑转回纯js的方案？实际上我确实有点怀疑这一点。因为插入innerHTML的耗费比parse要大。加上as存在与浏览器的通信问题（是否是跨进程通讯？最好检测一下，比如来回传递10k的字符串要多久），所以我很怀疑as版本实际上无法获得显著的性能提升。BTW，AS版本还有一个问题，我的机器本地无法看到效果，必须扔到一个http服务器上去看。也许是因为安全限制的原因。

这个倒没试过，我怀疑在as里面进行分析的时间极短，甚至在总时间很少很少的一部分；可能大部分时间花在innerHTML上面。

而js和as传递所消耗的时间也很短，和上面相比应该差不多，除非上面要分析几w行这样多的代码。

而用as获得的性能提升其实是显著的，js中遍历字符串的话会惨不忍睹的……可能在某些浏览器（最新的几个或者js执行速度很快的）里面还好，但其它的估计都会卡死大部分的。

as是有安全限制问题，必须部署到服务器上。除非用ie来看。我用ie7（maxthon）平时来调试的。

3 楼 hax 2009-04-17  

有没有单独的parse和拼接出html字符串的性能测试？

假设as的版本只比js快一点点，那么是否可以考虑转回纯js的方案？

实际上我确实有点怀疑这一点。因为插入innerHTML的耗费比parse要大。加上as存在与浏览器的通信问题（是否是跨进程通讯？最好检测一下，比如来回传递10k的字符串要多久），所以我很怀疑as版本实际上无法获得显著的性能提升。

BTW，AS版本还有一个问题，我的机器本地无法看到效果，必须扔到一个http服务器上去看。也许是因为安全限制的原因。

2 楼 Army 2009-04-17  

hax 写道

测试网页： https://pies.svn.sourceforge.net/svnroot/pies/trunk/2009/tiny-parser/jssc4/jssc4.html3400行代码，在我的机器上跑了20多秒。。。难道是我的机器有问题？我觉得原来纯js版的也不用20秒吧。https://pies.svn.sourceforge.net/svnroot/pies/trunk/2009/tiny-parser/jssc4/jssc4-large.html这个是完整的，9000多行代码，不敢跑。

找到问题了，不是由于as3的问题……在上面找了半天，浪费时间……

3400行基本上1秒搞定～

原因是出在js上面，因为关于折叠以及分配鼠标移入事件是在js中处理的，于是3400行代码后每行分析折叠以及分配一些事件，所以都卡在这上面了……

我想想办法～

1 楼 hax 2009-04-17  

测试网页： [url]https://pies.svn.sourceforge.net/svnroot/pies/trunk/2009/tiny-parser/jssc4/jssc4.html
[/url]
3400行代码，在我的机器上跑了20多秒。。。难道是我的机器有问题？
我觉得原来纯js版的也不用20秒吧。

https://pies.svn.sourceforge.net/svnroot/pies/trunk/2009/tiny-parser/jssc4/jssc4-large.html

这个是完整的，9000多行代码，不敢跑。