http://feed.cnblogs.com/blog/u/12973/category/177896/rss2012-05-27T20:32:45Zfeed.cnblogs.comhttp://www.cnblogs.com/JeffreyZhao/archive/2011/04/15/jscex-status-uglifyjs-parser-and-aot-compiler.html

Jscex项目是我为了简化JavaScript异步的一个类库，支持任意JavaScript（ECMASCript 3）引擎。Jscex小巧而强大，可以极大地改善前端的AJAX及动画等场景的编程体验，同样也可以用在node.js进行服务器开发。从产生Jscex的想法到现在也有几个月的时间了，也一直想设法进行推广。在思考过程也发现了它在实际生产中可能会遇到的问题，于是前两个星期的主要工作，便是针对这些问题进行优化。首先我将Jscex的JavaScript分析器从Narcissus换成了UglifyJS，并基于node.js开发了一个简单的AOT编译器。接下来我也打算写个稍微详细一点的介绍，然后在国外社区看看反响如何。

2011-04-14T18:09:00Z2011-04-14T18:09:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2011/01/14/be-clear-with-language-spec-and-platform-implementation-dotnet-cross-platform.html

在许多年前，“语言”就等同于“平台”，例如C，C++以及最早的Ruby和Python等等。但是随着技术发展，出现了一些通用的平台，例如.NET和Java，逐渐这些平台上的语言也越来越多。再后来，某些语言在不同平台上的实现也越来越多，事情也变得有些复杂。技术在发展，但是从目前社区的讨论中，我发现许多朋友的观念还没有跟上。简单地说，如今的观念，一定要从“语言即平台”切换成“语言及平台”，当分清“语言”和“平台”这两个不同事物之后，许多问题才能讨论地清楚。而且，这点对于.NET程序员来说尤为重要，因为C#语言可以说是目前“平台”、“实现”最为广泛的“语言”之一了。

2011-01-13T17:52:00Z2011-01-13T17:52:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2010/12/21/3rd-nbazaar-meeting-sign-up.html

为了错开年底密集的技术会议，第三届nBazaar技术交流会（即前“盛大创新院赞助的.NET技术交流会”）将于2011年1月15日举行。第三届的交流会将继续以往四场高质量的演讲，这也是确定nBazaar名称之后的第一次活动，希望nBazaar能够真正成为“集市”般热闹的社区活动。从现在开始，nBazaar技术沙龙的相关信息将逐渐集中至独立域名中，欢迎关注。

2010-12-20T16:49:00Z2010-12-20T16:49:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2010/09/25/things-about-padding-oracle-vulnerability-in-asp-net.html

上一周爆出了一个关于ASP.NET的安全漏洞，有关这个漏洞的第一篇文章应该是ScottGu的说明，但是其中各方面谈的也是语焉不详。由于这个漏洞关系到“安全”这样敏感的话题，其中又涉及到密码学这样常人看不明白的技术，于是导致了各种猜测和推测，其中甚至与我对ASP.NET的了解所有矛盾，因此我觉得也大都不靠谱。中秋休息在家，我简单地了解了一下与这个漏洞有关的内容，总结出了一些“能够说服自己”的内容，在此记录下来。因此，这篇文章的面向读者是那些和我差不多的同学：对ASP.NET有所了解，但对密码学知之甚少。

2010-09-24T18:28:00Z2010-09-24T18:28:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2010/07/02/1769605.html

firelong雄文又起，不过说实话，可能是这篇文章写的太简单了，其中的理由和结论都听得不是很明白。当然有一段话的意思很清楚（原话）：“C#事件的背后是一个委托链表（单链表），单链表的遍历调用性能远低于数组链表（List）”。这句话让我比较纳闷，因为从我的直觉来说，两种做法之间即使性能有差距，也不该是“远高于”啊。不过我提出这个疑问之后，firelong回应到（还是原话）“间接指针移动，和i++哪个快慢很难辨析吗？”于是我想，还是做个试验吧。

2010-07-01T17:21:00Z2010-07-01T17:21:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2010/06/24/first-snda-dotnet-conference-videos.html

经过几天的努力，终于将盛大创新院赞助的首届.NET技术交流会的演讲录像制作完成了。本来在现在的高清视频以外，我还想像Channel 9一样提供一些低码率的格式下载，但多次尝试都以失败告终，各中滋味难以言喻。因此目前只能给大家提供mov格式的高清视频下载，对于Windows下各类强大的播放器都不成问题。您也可以在线观看这些视频，不过上传至优酷后，发现除了清晰度较低外，甚至还有音画不同步的问题。我正在联系酷六网，会尽快用上质量更好的视频。

2010-06-24T14:34:00Z2010-06-24T14:34:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2010/02/26/mongodb-tokyo-tyrant-benchmark-2-concurrent-insert.html

在上一次的测试中我们比较了MongoDB与Tokyo Tyrant的Table Database两种存储方式的性能。不过由于条件限制，我只能在自己的MBP上测试，而这至少会带来两个问题。首先，真实环境下客户端和服务器是通过内网连接的，它的性能比本地回环要慢不少，一些和网络传输性能有关的问题可能会体现不出。其次，由于无法进行并发测试（并发测试的客户端资源占用较高，放在同一台机器上准确性较差），这又和生产环境有很大区别了。因此，我前两天向同事借了台性能测试用的机器，希望可以得到更可靠的结果。

2010-02-26T11:38:00Z2010-02-26T11:38:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/在上一次的测试中我们比较了MongoDB与Tokyo Tyrant的Table Database两种存储方式的性能。不过由于条件限制，我只能在自己的MBP上测试，而这至少会带来两个问题。首先，真实环境下客户端和服务器是通过内网连接的，它的性能比本地回环要慢不少，一些和网络传输性能有关的问题可能会体现不出。其次，由于无法进行并发测试（并发测试的客户端资源占用较高，放在同一台机器上准确性较差），这又和生产环境有很大区别了。因此，我前两天向同事借了台性能测试用的机器，希望可以得到更可靠的结果。http://www.cnblogs.com/JeffreyZhao/archive/2010/02/24/mongodb-tokyo-tyrant-benchmark-1-basic-cru-operations.html

以前的项目大都把数据存放在关系型数据库中，但是它们的问题比较明显的，一是在数据量上升的情况下伸缩性比较差，且进行结构调整的代价比较高。因此现在有个所谓NoSQL的“运动”也逐渐普遍起来了，它便是借助一些非关系型存储方式来开发项目。因此在新项目里，我也想尝试一下使用之前一直只是“听说”的存储方式。MongoDB和Tokyo Tyrant都是其中的典型代表，那么现在就来比较一下它们对于基本CRU操作的性能。

2010-02-24T15:45:00Z2010-02-24T15:45:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/以前的项目大都把数据存放在关系型数据库中，但是它们的问题比较明显的，一是在数据量上升的情况下伸缩性比较差，且进行结构调整的代价比较高。因此现在有个所谓NoSQL的“运动”也逐渐普遍起来了，它便是借助一些非关系型存储方式来开发项目。因此在新项目里，我也想尝试一下使用之前一直只是“听说”的存储方式。MongoDB和Tokyo Tyrant都是其中的典型代表，那么现在就来比较一下它们对于基本CRU操作的性能。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/29/sort-array-linq-5-object-size-and-performance.html

在我公开测试结果之后，有朋友也进行了其他测试。在测试中我使用的是int数组，经过分析之后我们了解到Array.Sort对于int数组有特殊的优化。于是，某些朋友使用了一些引用类型的数组进行排序，得到Array.Sort方法的性能落后于LINQ排序——虽然由于测试方式的问题，这个结果和结论都不太妥当。不过在讨论的过程中，我们都意识到了一个问题：在其他条件不变的情况下，引用类型的字段越多，Array.Sort方法所需时间就越久。这次我们就来讨论一下这个问题。

2010-01-28T16:09:00Z2010-01-28T16:09:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/在我公开测试结果之后，有朋友也进行了其他测试。在测试中我使用的是int数组，经过分析之后我们了解到Array.Sort对于int数组有特殊的优化。于是，某些朋友使用了一些引用类型的数组进行排序，得到Array.Sort方法的性能落后于LINQ排序——虽然由于测试方式的问题，这个结果和结论都不太妥当。不过在讨论的过程中，我们都意识到了一个问题：在其他条件不变的情况下，引用类型的字段越多，Array.Sort方法所需时间就越久。这次我们就来讨论一下这个问题。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/28/sort-array-linq-4-linq-style-array-sort.html

经过前两篇文章的分析，我们已经了解了Array.Sort与LINQ排序两种实现方式的差别：前者直接比较两个元素的大小，而后者先选出每个元素的“排序依据”再进行比较。因此，虽然后者需要相对较多的“周边工作”，但由于每次比较时都可以仅仅使用高效的基础类型（如int），因此从整体来看，两者的性能高低难以辨别。不过，既然我们已经了解LINQ排序“高效”的原因，又能否将其利用在数组排序上呢？程序是人写的，此类问题大都有肯定的答案。那么我们现在就来实现一下。

2010-01-27T16:06:00Z2010-01-27T16:06:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/经过前两篇文章的分析，我们已经了解了Array.Sort与LINQ排序两种实现方式的差别：前者直接比较两个元素的大小，而后者先选出每个元素的“排序依据”再进行比较。因此，虽然后者需要相对较多的“周边工作”，但由于每次比较时都可以仅仅使用高效的基础类型（如int），因此从整体来看，两者的性能高低难以辨别。不过，既然我们已经了解LINQ排序“高效”的原因，又能否将其利用在数组排序上呢？程序是人写的，此类问题大都有肯定的答案。那么我们现在就来实现一下。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/27/sort-array-linq-3-linq-sort.html

上次我们分析了Array.Sort方法的实现方式，并了解到类库会为一些特例而使用高性能的排序方式——int数组便是这样一例，因此从测试结果上来看其性能特别高。不过从数据上看，即便是在普通的情况下，Array.Sort的性能也比LINQ排序要高。不过也有朋友从测试中得出的结论正好相反，这又是为什么呢？那么现在，我们再来分析一下LINQ排序的实现方式吧，希望这样可以了解到两者性能差别的秘密。

2010-01-26T16:02:00Z2010-01-26T16:02:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/上次我们分析了Array.Sort方法的实现方式，并了解到类库会为一些特例而使用高性能的排序方式——int数组便是这样一例，因此从测试结果上来看其性能特别高。不过从数据上看，即便是在普通的情况下，Array.Sort的性能也比LINQ排序要高。不过也有朋友从测试中得出的结论正好相反，这又是为什么呢？那么现在，我们再来分析一下LINQ排序的实现方式吧，希望这样可以了解到两者性能差别的秘密。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/22/sort-array-linq-2-array-sort.html

昨天我们比较了Array.Sort方法与LINQ排序的性能，知道了LINQ排序的性能以较大幅度落后于Array.Sort方法。而对于Array.Sort来说，性能最高的是其中使用Comparer.Default作为比较器的重载方法。在前文的末尾我们做出了推测：由于排序算法已经近乎一个标准了（快速排序），因此从算法角度来说，Array.Sort方法和LINQ排序上不应该有那么大的差距，因此造成两者性能差异的原因，应该是具体实现方式上的问题。

2010-01-21T16:06:00Z2010-01-21T16:06:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/昨天我们比较了Array.Sort方法与LINQ排序的性能，知道了LINQ排序的性能以较大幅度落后于Array.Sort方法。而对于Array.Sort来说，性能最高的是其中使用Comparer.Default作为比较器的重载方法。在前文的末尾我们做出了推测：由于排序算法已经近乎一个标准了（快速排序），因此从算法角度来说，Array.Sort方法和LINQ排序上不应该有那么大的差距，因此造成两者性能差异的原因，应该是具体实现方式上的问题。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/21/sort-array-linq-1-notes-and-benchmark.html

昨天有朋友写了一篇文章，其中比较了List的Sort方法与LINQ中排序方法的性能，而最终得到的结果是“LINQ排序方法性能高于List.Sort方法”。这个结果不禁让我很疑惑。因为List.Sort方法是改变容器内部元素的顺序，而LINQ排序后得到的是一个新的序列。假如两个排序方法的算法完全一致，LINQ排序也比对方多出元素复制的开销，为什么性能反而会高？如果LINQ排序的算法/实现更为优秀，那为什么.NET Fx不将List.Sort也一并优化一下呢？于是今天我也对这个问题进行了简单的试验。

2010-01-20T16:11:00Z2010-01-20T16:11:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/昨天有朋友写了一篇文章，其中比较了List的Sort方法与LINQ中排序方法的性能，而最终得到的结果是“LINQ排序方法性能高于List.Sort方法”。这个结果不禁让我很疑惑。因为List.Sort方法是改变容器内部元素的顺序，而LINQ排序后得到的是一个新的序列。假如两个排序方法的算法完全一致，LINQ排序也比对方多出元素复制的开销，为什么性能反而会高？如果LINQ排序的算法/实现更为优秀，那为什么.NET Fx不将List.Sort也一并优化一下呢？于是今天我也对这个问题进行了简单的试验。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/14/talk-about-code-performance-4-asm-optimization.html

终于谈到这个话题了，首先声明我不是汇编优化的高手，甚至于我知道的所有关于汇编优化的内容，仅仅来自于学校的课程、书本及当年做过的一些简单练习。换句话说，我了解的东西只能算是一些原则，甚至也有一些“陈旧”了——不过我想既然是一些原则性的东西，还是能够用它来做一定程度的判断。至少我认为，我在博客园里看到的许多关于“汇编优化”也好，“内嵌汇编”也罢的说法，经常是有些问题的。

2010-01-13T16:08:00Z2010-01-13T16:08:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/终于谈到这个话题了，首先声明我不是汇编优化的高手，甚至于我知道的所有关于汇编优化的内容，仅仅来自于学校的课程、书本及当年做过的一些简单练习。换句话说，我了解的东西只能算是一些原则，甚至也有一些“陈旧”了——不过我想既然是一些原则性的东西，还是能够用它来做一定程度的判断。至少我认为，我在博客园里看到的许多关于“汇编优化”也好，“内嵌汇编”也罢的说法，经常是有些问题的。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/12/talk-about-code-performance-3-locality.html

在前两篇文章里，我们讨论了程序性能的两个方面，一是算法（广义的算法，即解决问题的方法），二是编译器。通过这两个方面，我想表达的意思是，一段程序的执行效率，是很难从表面现象得出结论的，至少从一些简单的层面，如代码的长度是几乎难以说明任何问题——因此一定要进行Profiling才能做到有效的优化。而现在，我们假设两段程序算法基本相同，编译器也只是进行简单的“翻译”，那么……我们能从“表面”看出性能高下吗？

2010-01-11T16:03:00Z2010-01-11T16:03:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/在前两篇文章里，我们讨论了程序性能的两个方面，一是算法（广义的算法，即解决问题的方法），二是编译器。通过这两个方面，我想表达的意思是，一段程序的执行效率，是很难从表面现象得出结论的，至少从一些简单的层面，如代码的长度是几乎难以说明任何问题——因此一定要进行Profiling才能做到有效的优化。而现在，我们假设两段程序算法基本相同，编译器也只是进行简单的“翻译”，那么……我们能从“表面”看出性能高下吗？http://www.cnblogs.com/JeffreyZhao/archive/2010/01/08/talk-about-code-performance-2-compiler.html

在上一篇文章中，我主要表达了这样一个观点：影响程序效率的关键之一是算法，而算法的选择与优化，和是否多一个赋值少一个判断的关系不大。关于算法的选择，我谈到其理论上的复杂度，并不直接反映出效率。因为在实际运用时，数据的规模，形式等等都会涉及到算法的实际效用。一个时间复杂度低的算法并不代表任何情况下的效率都高。这是“实际”和“理论”的区别之一。现在我打算来谈一下另一个比较“实际”的东西：编译器对于程序效率的影响。

2010-01-07T16:06:00Z2010-01-07T16:06:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/在上一篇文章中，我主要表达了这样一个观点：影响程序效率的关键之一是算法，而算法的选择与优化，和是否多一个赋值少一个判断的关系不大。关于算法的选择，我谈到其理论上的复杂度，并不直接反映出效率。因为在实际运用时，数据的规模，形式等等都会涉及到算法的实际效用。一个时间复杂度低的算法并不代表任何情况下的效率都高。这是“实际”和“理论”的区别之一。现在我打算来谈一下另一个比较“实际”的东西：编译器对于程序效率的影响。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/07/short-code-is-not-always-fast-1-algorithms.html

前一段时间在博客园里看到这样一篇文章，那位兄弟谈到程序效率的关键是“简短”。他说，“程序越简短，其可执行代码就越少，就越有效率”，而在编写程序的时候，“要尽量改进我们的算法，而改进算法中最重要的一条，就是减少语句”。这句话从表面上似乎正确，但我认为性能这问题不能用“简短”这种方式去思考，否则会进入一些误区。我整理了一下思路，希望可以从几个方面把详细谈一下这个问题。首先我想说的是：“简短”不是关键，“算法”更加重要。

2010-01-07T09:14:00Z2010-01-07T09:14:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/前一段时间在博客园里看到这样一篇文章，那位兄弟谈到程序效率的关键是“简短”。他说，“程序越简短，其可执行代码就越少，就越有效率”，而在编写程序的时候，“要尽量改进我们的算法，而改进算法中最重要的一条，就是减少语句”。这句话从表面上似乎正确，但我认为性能这问题不能用“简短”这种方式去思考，否则会进入一些误区。我整理了一下思路，希望可以从几个方面把详细谈一下这个问题。首先我想说的是：“简短”不是关键，“算法”更加重要。http://www.cnblogs.com/JeffreyZhao/archive/2010/01/03/fsharp-xml-serialization.html

这两天在用F#写一小段代码，需要把一些对象存到外部文件中去。这个功能很容易，因为.NET本身就内置了序列化功能。方便起见，我打算将这个对象序列化成XML而不是二进制数据流。这意味着我需要使用XmlSerializer而不是BinaryFormatter。这本应没有问题，但是在使用时候还是发生了一些小插曲。

2010-01-03T13:24:00Z2010-01-03T13:24:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/这两天在用F#写一小段代码，需要把一些对象存到外部文件中去。这个功能很容易，因为.NET本身就内置了序列化功能。方便起见，我打算将这个对象序列化成XML而不是二进制数据流。这意味着我需要使用XmlSerializer而不是BinaryFormatter。这本应没有问题，但是在使用时候还是发生了一些小插曲。http://www.cnblogs.com/JeffreyZhao/archive/2009/12/29/fiddler-infoq-video.html

InfoQ是一个好地方，而我认为其中最有价值的资源，便是其中的演讲视频。InfoQ在这方面有个特点：在演讲视频下方提供了清晰的幻灯片，而在播放的同时，还会根据进度进行切换。这观看体验自然比单纯的演讲录像要高出许多。可惜的是，时不时有朋友会向我反馈说，InfoQ实在是太慢，几乎无法流畅地观看视频。由于一时半会儿InfoQ也不会在中国放CDN，因此视频加载速度这问题……几乎无法解决。还好，如果我们退而求其次，至少可以使用Fiddler等工具来“缓解”这个问题。

2009-12-29T04:04:00Z2009-12-29T04:04:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/InfoQ是一个好地方，而我认为其中最有价值的资源，便是其中的演讲视频。InfoQ在这方面有个特点：在演讲视频下方提供了清晰的幻灯片，而在播放的同时，还会根据进度进行切换。这观看体验自然比单纯的演讲录像要高出许多。可惜的是，时不时有朋友会向我反馈说，InfoQ实在是太慢，几乎无法流畅地观看视频。由于一时半会儿InfoQ也不会在中国放CDN，因此视频加载速度这问题……几乎无法解决。还好，如果我们退而求其次，至少可以使用Fiddler等工具来“缓解”这个问题。http://www.cnblogs.com/JeffreyZhao/archive/2009/12/23/string-concat-perf-3-profiling-analysis.html

经过之间的性能比较，我们得知StringBuilder的性能并非时时最优，再经过实现分析，我们大致了解了StringBuilder的实现方式。虽然在此之前，大家也基本已经了解StringBuilder的实现原理，也有不少朋友指出了它性能缺陷的原因。不过“严谨”起见，寻找性能问题的方式应该是进行Profiling，然后找出性能关键再进行优化——而不是纯粹进行“阅读”这种静态分析方式。

2009-12-23T06:03:00Z2009-12-23T06:03:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/经过之间的性能比较，我们得知StringBuilder的性能并非时时最优，再经过实现分析，我们大致了解了StringBuilder的实现方式。虽然在此之前，大家也基本已经了解StringBuilder的实现原理，也有不少朋友指出了它性能缺陷的原因。不过“严谨”起见，寻找性能问题的方式应该是进行Profiling，然后找出性能关键再进行优化——而不是纯粹进行“阅读”这种静态分析方式。