<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom"><title type="text">博客园_老赵点滴 - 追求编程之美_分类_01. DotNet框架</title><id>http://feed.cnblogs.com/blog/u/12973/category/129812/rss</id><updated>2012-05-27T20:32:29Z</updated><generator>feed.cnblogs.com</generator><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/category/129812.html"/><link rel="self" type="application/atom+xml" href="http://feed.cnblogs.com/blog/u/12973/category/129812/rss"/><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2011/01/14/be-clear-with-language-spec-and-platform-implementation-dotnet-cross-platform.html</id><title type="text">分清“语言/规范”以及“平台/实现”，以及跨平台.NET开发</title><summary type="text">在许多年前，“语言”就等同于“平台”，例如C，C++以及最早的Ruby和Python等等。但是随着技术发展，出现了一些通用的平台，例如.NET和Java，逐渐这些平台上的语言也越来越多。再后来，某些语言在不同平台上的实现也越来越多，事情也变得有些复杂。技术在发展，但是从目前社区的讨论中，我发现许多朋友的观念还没有跟上。简单地说，如今的观念，一定要从“语言即平台”切换成“语言及平台”，当分清“语言”和“平台”这两个不同事物之后，许多问题才能讨论地清楚。而且，这点对于.NET程序员来说尤为重要，因为C#语言可以说是目前“平台”、“实现”最为广泛的“语言”之一了。</summary><published>2011-01-13T17:52:00Z</published><updated>2011-01-13T17:52:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2011/01/14/be-clear-with-language-spec-and-platform-implementation-dotnet-cross-platform.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2011/01/14/be-clear-with-language-spec-and-platform-implementation-dotnet-cross-platform.html"/><content type="html"/></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/12/21/3rd-nbazaar-meeting-sign-up.html</id><title type="text">第三届nBazaar技术交流会开始报名</title><summary type="text">为了错开年底密集的技术会议，第三届nBazaar技术交流会（即前“盛大创新院赞助的.NET技术交流会”）将于2011年1月15日举行。第三届的交流会将继续以往四场高质量的演讲，这也是确定nBazaar名称之后的第一次活动，希望nBazaar能够真正成为“集市”般热闹的社区活动。从现在开始，nBazaar技术沙龙的相关信息将逐渐集中至独立域名中，欢迎关注。</summary><published>2010-12-20T16:49:00Z</published><updated>2010-12-20T16:49:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/12/21/3rd-nbazaar-meeting-sign-up.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/12/21/3rd-nbazaar-meeting-sign-up.html"/><content type="html"/></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/07/13/ndc-2010-videos.html</id><title type="text">NDC 2010视频下载：看看其他微软平台程序员们都在做什么</title><summary type="text">NDC（Norwegian Developers Conference，挪威开发者大会）是一年一度的挪威最大的微软平台开发者大会，内容丰富，讲师阵容强大。NDC与PDC同为高端技术会议，但NDC与PDC的不同之处在于，PDC是微软官方会议，主要是面向微软资深产品的深入探讨。而NDC涉及的内容则广泛的多，包括了我所感兴趣的Java、Mono、IronRuby/Ruby on Rails、NoSQL方面的内容。这也就像我一直强调的那样，微软技术社区非常开放，微软平台上的太多程序员都能够非常热情地拥抱其他平台的技术。那些认为微软技术社区是井底之蛙的兄弟，殊不知你们的嘲笑反而体现了自身的狭隘。</summary><published>2010-07-13T07:19:00Z</published><updated>2010-07-13T07:19:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/07/13/ndc-2010-videos.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/07/13/ndc-2010-videos.html"/><content type="html"/></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/04/05/fsharp-for-asp-net-2-implement-event-based-asynchronous-pattern-with-fsharp.html</id><title type="text">F#与ASP.NET（2）：使用F#实现基于事件的异步模式</title><summary type="text">在上一篇文章中，我们的简单讨论了.NET中两种异步模型以及它们在异常处理上的区别，并且简单观察了ASP.NET MVC 2中异步Action的编写方式。从中我们得知，ASP.NET MVC 2的异步Action并非使用了传统基于Begin/End的异步编程模型，而是另一种基于事件的异步模式。此外，ASP.NET MVC 2对于这种异步模式提供了必要的支持，使此方面的程序设计变得相对简单一些。但是，简单的原因主要还是在于已经由其他组件提供了良好的，基于事件的异步模式。那么现在我们就来看看一般我们应该如何来实现这样的功能，以及F#是如何美化我们的生活的吧。</summary><published>2010-04-05T12:46:00Z</published><updated>2010-04-05T12:46:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/04/05/fsharp-for-asp-net-2-implement-event-based-asynchronous-pattern-with-fsharp.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/04/05/fsharp-for-asp-net-2-implement-event-based-asynchronous-pattern-with-fsharp.html"/><content type="text">在上一篇文章中，我们的简单讨论了.NET中两种异步模型以及它们在异常处理上的区别，并且简单观察了ASP.NET MVC 2中异步Action的编写方式。从中我们得知，ASP.NET MVC 2的异步Action并非使用了传统基于Begin/End的异步编程模型，而是另一种基于事件的异步模式。此外，ASP.NET MVC 2对于这种异步模式提供了必要的支持，使此方面的程序设计变得相对简单一些。但是，简单的原因主要还是在于已经由其他组件提供了良好的，基于事件的异步模式。那么现在我们就来看看一般我们应该如何来实现这样的功能，以及F#是如何美化我们的生活的吧。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/03/26/snda-dotnet-conference-advices.html</id><title type="text">盛大创新院赞助.NET技术会议意见征询</title><summary type="text">各位可能大都知道，我于不久前加入了盛大创新院。最近我了解到，创新院这边对于社区开展技术会议的活动也是相当支持的，并且对每个社区的会议会有资金和人员上的支持。这几天我和副院长聊了一下，他表示只要组织得当，创新院也支持把技术交流会办成一个有规律的活动，定期举行。事实上，创新院已经赞助过多次Flash及产品设计方面的技术会议。当然，会议的目的是进行技术交流，对观众自然是完全免费的。因此，我打算在5月或6月份在上海举办一次.NET技术会议，在此征求一下您的意见。</summary><published>2010-03-26T07:54:00Z</published><updated>2010-03-26T07:54:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/03/26/snda-dotnet-conference-advices.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/03/26/snda-dotnet-conference-advices.html"/><content type="text">各位可能大都知道，我于不久前加入了盛大创新院。最近我了解到，创新院这边对于社区开展技术会议的活动也是相当支持的，并且对每个社区的会议会有资金和人员上的支持。这几天我和副院长聊了一下，他表示只要组织得当，创新院也支持把技术交流会办成一个有规律的活动，定期举行。事实上，创新院已经赞助过多次Flash及产品设计方面的技术会议。当然，会议的目的是进行技术交流，对观众自然是完全免费的。因此，我打算在5月或6月份在上海举办一次.NET技术会议，在此征求一下您的意见。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/02/22/why-not-csharp-on-jvm-type-erasure.html</id><title type="text">为什么JVM上没有C#语言？浅谈Type Erasure特性</title><summary type="text">JVM上目前已经有许多语言了：JRuby，Jython，也有一些特定于JVM平台的语言，如Scala和Groovy等。但是，为什么JVM上没有C#语言呢？按理说，这门和Java十分相似，却又强大许多的语言更容易被Java程序员接受才对。有人说，Sun和微软是对头，怎么可能将C#移植到JVM平台上呢？嗯，有道理，但是为什么社区里也没有人这么做呢（要知道JVM上其他语言都是由社区发起的）？其实在我看来，这是受到了技术方面的限制。例如：Type Erasure。</summary><published>2010-02-22T15:50:00Z</published><updated>2010-02-22T15:50:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/02/22/why-not-csharp-on-jvm-type-erasure.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/02/22/why-not-csharp-on-jvm-type-erasure.html"/><content type="text">JVM上目前已经有许多语言了：JRuby，Jython，也有一些特定于JVM平台的语言，如Scala和Groovy等。但是，为什么JVM上没有C#语言呢？按理说，这门和Java十分相似，却又强大许多的语言更容易被Java程序员接受才对。有人说，Sun和微软是对头，怎么可能将C#移植到JVM平台上呢？嗯，有道理，但是为什么社区里也没有人这么做呢（要知道JVM上其他语言都是由社区发起的）？其实在我看来，这是受到了技术方面的限制。例如：Type Erasure。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/02/10/byte-order-and-related-library.html</id><title type="text">浅谈字节序（Byte Order）及其相关操作</title><summary type="text">最近在为Tokyo Tyrant写一个.NET客户端类库。Tokyo Tyrant公开了一个基于TCP协议的二进制协议，于是我们的工作其实也只是按照协议发送和读取一些二进制数据流而已，并不麻烦。不过在其中涉及到了“字节序”的概念，这本是计算机体系结构/操作系统等课程的基础，不过我还是打算在这里进行简单说明，并且对.NET中部分类库在此类数据流处理时的注意事项进行些许记录与总结。</summary><published>2010-02-10T15:05:00Z</published><updated>2010-02-10T15:05:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/02/10/byte-order-and-related-library.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/02/10/byte-order-and-related-library.html"/><content type="text">最近在为Tokyo Tyrant写一个.NET客户端类库。Tokyo Tyrant公开了一个基于TCP协议的二进制协议，于是我们的工作其实也只是按照协议发送和读取一些二进制数据流而已，并不麻烦。不过在其中涉及到了“字节序”的概念，这本是计算机体系结构/操作系统等课程的基础，不过我还是打算在这里进行简单说明，并且对.NET中部分类库在此类数据流处理时的注意事项进行些许记录与总结。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/02/03/twitter-talk-about-ms-dev-at-20100201.html</id><title type="text">李笑来激起千层浪，赵姐夫力拒众强敌</title><summary type="text">昨天晚上，李笑来（@xiaolai）老师的无心之语却引起了推特上一次前后长达1个多小时的讨论——当时他似乎只是随手发了一句“Apple告诉我们的铁律是：表面功夫一定要做足”便不见了踪影，但是这句话立即引起了众果粉的共鸣。此后，我（@jeffz_cn）的一句评论又引起了众人对微软开发平台的批判之声。在这次讨论中，几乎只有我孤军奋战为.NET平台进行辩解。因此事后有人给出一副对联为此次争论作出总结：李笑来激起千层浪，赵姐夫力拒众强敌。</summary><published>2010-02-02T16:49:00Z</published><updated>2010-02-02T16:49:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/02/03/twitter-talk-about-ms-dev-at-20100201.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/02/03/twitter-talk-about-ms-dev-at-20100201.html"/><content type="text">昨天晚上，李笑来（@xiaolai）老师的无心之语却引起了推特上一次前后长达1个多小时的讨论——当时他似乎只是随手发了一句“Apple告诉我们的铁律是：表面功夫一定要做足”便不见了踪影，但是这句话立即引起了众果粉的共鸣。此后，我（@jeffz_cn）的一句评论又引起了众人对微软开发平台的批判之声。在这次讨论中，几乎只有我孤军奋战为.NET平台进行辩解。因此事后有人给出一副对联为此次争论作出总结：李笑来激起千层浪，赵姐夫力拒众强敌。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/29/sort-array-linq-5-object-size-and-performance.html</id><title type="text">数组排序方法的性能比较（5）：对象大小与排序性能</title><summary type="text">在我公开测试结果之后，有朋友也进行了其他测试。在测试中我使用的是int数组，经过分析之后我们了解到Array.Sort对于int数组有特殊的优化。于是，某些朋友使用了一些引用类型的数组进行排序，得到Array.Sort方法的性能落后于LINQ排序——虽然由于测试方式的问题，这个结果和结论都不太妥当。不过在讨论的过程中，我们都意识到了一个问题：在其他条件不变的情况下，引用类型的字段越多，Array.Sort方法所需时间就越久。这次我们就来讨论一下这个问题。</summary><published>2010-01-28T16:09:00Z</published><updated>2010-01-28T16:09:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/29/sort-array-linq-5-object-size-and-performance.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/29/sort-array-linq-5-object-size-and-performance.html"/><content type="text">在我公开测试结果之后，有朋友也进行了其他测试。在测试中我使用的是int数组，经过分析之后我们了解到Array.Sort对于int数组有特殊的优化。于是，某些朋友使用了一些引用类型的数组进行排序，得到Array.Sort方法的性能落后于LINQ排序——虽然由于测试方式的问题，这个结果和结论都不太妥当。不过在讨论的过程中，我们都意识到了一个问题：在其他条件不变的情况下，引用类型的字段越多，Array.Sort方法所需时间就越久。这次我们就来讨论一下这个问题。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/28/sort-array-linq-4-linq-style-array-sort.html</id><title type="text">数组排序方法的性能比较（4）：LINQ方式的Array排序</title><summary type="text">经过前两篇文章的分析，我们已经了解了Array.Sort与LINQ排序两种实现方式的差别：前者直接比较两个元素的大小，而后者先选出每个元素的“排序依据”再进行比较。因此，虽然后者需要相对较多的“周边工作”，但由于每次比较时都可以仅仅使用高效的基础类型（如int），因此从整体来看，两者的性能高低难以辨别。不过，既然我们已经了解LINQ排序“高效”的原因，又能否将其利用在数组排序上呢？程序是人写的，此类问题大都有肯定的答案。那么我们现在就来实现一下。</summary><published>2010-01-27T16:06:00Z</published><updated>2010-01-27T16:06:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/28/sort-array-linq-4-linq-style-array-sort.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/28/sort-array-linq-4-linq-style-array-sort.html"/><content type="text">经过前两篇文章的分析，我们已经了解了Array.Sort与LINQ排序两种实现方式的差别：前者直接比较两个元素的大小，而后者先选出每个元素的“排序依据”再进行比较。因此，虽然后者需要相对较多的“周边工作”，但由于每次比较时都可以仅仅使用高效的基础类型（如int），因此从整体来看，两者的性能高低难以辨别。不过，既然我们已经了解LINQ排序“高效”的原因，又能否将其利用在数组排序上呢？程序是人写的，此类问题大都有肯定的答案。那么我们现在就来实现一下。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/27/sort-array-linq-3-linq-sort.html</id><title type="text">数组排序方法的性能比较（3）：LINQ排序实现分析</title><summary type="text">上次我们分析了Array.Sort方法的实现方式，并了解到类库会为一些特例而使用高性能的排序方式——int数组便是这样一例，因此从测试结果上来看其性能特别高。不过从数据上看，即便是在普通的情况下，Array.Sort的性能也比LINQ排序要高。不过也有朋友从测试中得出的结论正好相反，这又是为什么呢？那么现在，我们再来分析一下LINQ排序的实现方式吧，希望这样可以了解到两者性能差别的秘密。</summary><published>2010-01-26T16:02:00Z</published><updated>2010-01-26T16:02:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/27/sort-array-linq-3-linq-sort.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/27/sort-array-linq-3-linq-sort.html"/><content type="text">上次我们分析了Array.Sort方法的实现方式，并了解到类库会为一些特例而使用高性能的排序方式——int数组便是这样一例，因此从测试结果上来看其性能特别高。不过从数据上看，即便是在普通的情况下，Array.Sort的性能也比LINQ排序要高。不过也有朋友从测试中得出的结论正好相反，这又是为什么呢？那么现在，我们再来分析一下LINQ排序的实现方式吧，希望这样可以了解到两者性能差别的秘密。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/26/decompile-methods-with-yield-manually.html</id><title type="text">人肉反编译使用yield关键字的方法</title><summary type="text">我认为这是一个真命题：“没有用.NET Reflector反编译并阅读过代码的程序员不是专业的.NET程序员”。.NET Reflector强大的地方就在于可以把IL代码反编译成可读性颇高的高级语言代码，并且能够支持相当多的“模式”，根据这些模式它可以在一定程度上把某些语法糖给还原，甚至可以支持简单的Lambda表达式和LINQ。只可惜，.NET Reflector还是无法做到极致，某些情况下生成的代码还是无法还原到易于理解——yield关键字便是这样一个典型的情况。不过还行，对于不复杂的逻辑，我们可以通过人肉来“整理”个大概。</summary><published>2010-01-25T16:06:00Z</published><updated>2010-01-25T16:06:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/26/decompile-methods-with-yield-manually.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/26/decompile-methods-with-yield-manually.html"/><content type="text">我认为这是一个真命题：“没有用.NET Reflector反编译并阅读过代码的程序员不是专业的.NET程序员”。.NET Reflector强大的地方就在于可以把IL代码反编译成可读性颇高的高级语言代码，并且能够支持相当多的“模式”，根据这些模式它可以在一定程度上把某些语法糖给还原，甚至可以支持简单的Lambda表达式和LINQ。只可惜，.NET Reflector还是无法做到极致，某些情况下生成的代码还是无法还原到易于理解——yield关键字便是这样一个典型的情况。不过还行，对于不复杂的逻辑，我们可以通过人肉来“整理”个大概。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/22/sort-array-linq-2-array-sort.html</id><title type="text">数组排序方法的性能比较（2）：Array.Sort&amp;lt;T&amp;gt;实现分析</title><summary type="text">昨天我们比较了Array.Sort方法与LINQ排序的性能，知道了LINQ排序的性能以较大幅度落后于Array.Sort方法。而对于Array.Sort来说，性能最高的是其中使用Comparer.Default作为比较器的重载方法。在前文的末尾我们做出了推测：由于排序算法已经近乎一个标准了（快速排序），因此从算法角度来说，Array.Sort方法和LINQ排序上不应该有那么大的差距，因此造成两者性能差异的原因，应该是具体实现方式上的问题。</summary><published>2010-01-21T16:06:00Z</published><updated>2010-01-21T16:06:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/22/sort-array-linq-2-array-sort.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/22/sort-array-linq-2-array-sort.html"/><content type="text">昨天我们比较了Array.Sort方法与LINQ排序的性能，知道了LINQ排序的性能以较大幅度落后于Array.Sort方法。而对于Array.Sort来说，性能最高的是其中使用Comparer.Default作为比较器的重载方法。在前文的末尾我们做出了推测：由于排序算法已经近乎一个标准了（快速排序），因此从算法角度来说，Array.Sort方法和LINQ排序上不应该有那么大的差距，因此造成两者性能差异的原因，应该是具体实现方式上的问题。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/21/sort-array-linq-1-notes-and-benchmark.html</id><title type="text">数组排序方法的性能比较（1）：注意事项及试验</title><summary type="text">昨天有朋友写了一篇文章，其中比较了List的Sort方法与LINQ中排序方法的性能，而最终得到的结果是“LINQ排序方法性能高于List.Sort方法”。这个结果不禁让我很疑惑。因为List.Sort方法是改变容器内部元素的顺序，而LINQ排序后得到的是一个新的序列。假如两个排序方法的算法完全一致，LINQ排序也比对方多出元素复制的开销，为什么性能反而会高？如果LINQ排序的算法/实现更为优秀，那为什么.NET Fx不将List.Sort也一并优化一下呢？于是今天我也对这个问题进行了简单的试验。</summary><published>2010-01-20T16:11:00Z</published><updated>2010-01-20T16:11:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/21/sort-array-linq-1-notes-and-benchmark.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/21/sort-array-linq-1-notes-and-benchmark.html"/><content type="text">昨天有朋友写了一篇文章，其中比较了List的Sort方法与LINQ中排序方法的性能，而最终得到的结果是“LINQ排序方法性能高于List.Sort方法”。这个结果不禁让我很疑惑。因为List.Sort方法是改变容器内部元素的顺序，而LINQ排序后得到的是一个新的序列。假如两个排序方法的算法完全一致，LINQ排序也比对方多出元素复制的开销，为什么性能反而会高？如果LINQ排序的算法/实现更为优秀，那为什么.NET Fx不将List.Sort也一并优化一下呢？于是今天我也对这个问题进行了简单的试验。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/14/talk-about-code-performance-4-asm-optimization.html</id><title type="text">浅谈代码的执行效率（4）：汇编优化</title><summary type="text">终于谈到这个话题了，首先声明我不是汇编优化的高手，甚至于我知道的所有关于汇编优化的内容，仅仅来自于学校的课程、书本及当年做过的一些简单练习。换句话说，我了解的东西只能算是一些原则，甚至也有一些“陈旧”了——不过我想既然是一些原则性的东西，还是能够用它来做一定程度的判断。至少我认为，我在博客园里看到的许多关于“汇编优化”也好，“内嵌汇编”也罢的说法，经常是有些问题的。</summary><published>2010-01-13T16:08:00Z</published><updated>2010-01-13T16:08:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/14/talk-about-code-performance-4-asm-optimization.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/14/talk-about-code-performance-4-asm-optimization.html"/><content type="text">终于谈到这个话题了，首先声明我不是汇编优化的高手，甚至于我知道的所有关于汇编优化的内容，仅仅来自于学校的课程、书本及当年做过的一些简单练习。换句话说，我了解的东西只能算是一些原则，甚至也有一些“陈旧”了——不过我想既然是一些原则性的东西，还是能够用它来做一定程度的判断。至少我认为，我在博客园里看到的许多关于“汇编优化”也好，“内嵌汇编”也罢的说法，经常是有些问题的。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/12/talk-about-code-performance-3-locality.html</id><title type="text">浅谈代码的执行效率（3）：缓存与局部性</title><summary type="text">在前两篇文章里，我们讨论了程序性能的两个方面，一是算法（广义的算法，即解决问题的方法），二是编译器。通过这两个方面，我想表达的意思是，一段程序的执行效率，是很难从表面现象得出结论的，至少从一些简单的层面，如代码的长度是几乎难以说明任何问题——因此一定要进行Profiling才能做到有效的优化。而现在，我们假设两段程序算法基本相同，编译器也只是进行简单的“翻译”，那么……我们能从“表面”看出性能高下吗？</summary><published>2010-01-11T16:03:00Z</published><updated>2010-01-11T16:03:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/12/talk-about-code-performance-3-locality.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/12/talk-about-code-performance-3-locality.html"/><content type="text">在前两篇文章里，我们讨论了程序性能的两个方面，一是算法（广义的算法，即解决问题的方法），二是编译器。通过这两个方面，我想表达的意思是，一段程序的执行效率，是很难从表面现象得出结论的，至少从一些简单的层面，如代码的长度是几乎难以说明任何问题——因此一定要进行Profiling才能做到有效的优化。而现在，我们假设两段程序算法基本相同，编译器也只是进行简单的“翻译”，那么……我们能从“表面”看出性能高下吗？</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/11/fsharp-per-user-posts-by-month-statistics.html</id><title type="text">按月统计博客园单个用户的发文数量</title><summary type="text">这几天在家闲着，便试着写一些小程序。之前有朋友问到“F#能不能写Web”，于是我也就打算这么一试。虽然我能肯定，用F#写Web应用程序不会是问题，不过倒真还没有做过这方面的尝试。我想，如果用F#写Web应用程序，那么它很重要的一点，应该是利用其在异步编程方面的强大特性。最后我决定，使用F#编写一个按月统计博客园单个用户发文数量的简单服务。尝试的结果是——还有些问题没有解决。不管怎么样，我先把其主体逻辑描述一下吧。</summary><published>2010-01-10T16:07:00Z</published><updated>2010-01-10T16:07:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/11/fsharp-per-user-posts-by-month-statistics.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/11/fsharp-per-user-posts-by-month-statistics.html"/><content type="text">这几天在家闲着，便试着写一些小程序。之前有朋友问到“F#能不能写Web”，于是我也就打算这么一试。虽然我能肯定，用F#写Web应用程序不会是问题，不过倒真还没有做过这方面的尝试。我想，如果用F#写Web应用程序，那么它很重要的一点，应该是利用其在异步编程方面的强大特性。最后我决定，使用F#编写一个按月统计博客园单个用户发文数量的简单服务。尝试的结果是——还有些问题没有解决。不管怎么样，我先把其主体逻辑描述一下吧。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2010/01/08/talk-about-code-performance-2-compiler.html</id><title type="text">浅谈代码的执行效率（2）：编译器的威力</title><summary type="text">在上一篇文章中，我主要表达了这样一个观点：影响程序效率的关键之一是算法，而算法的选择与优化，和是否多一个赋值少一个判断的关系不大。关于算法的选择，我谈到其理论上的复杂度，并不直接反映出效率。因为在实际运用时，数据的规模，形式等等都会涉及到算法的实际效用。一个时间复杂度低的算法并不代表任何情况下的效率都高。这是“实际”和“理论”的区别之一。现在我打算来谈一下另一个比较“实际”的东西：编译器对于程序效率的影响。</summary><published>2010-01-07T16:06:00Z</published><updated>2010-01-07T16:06:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/08/talk-about-code-performance-2-compiler.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2010/01/08/talk-about-code-performance-2-compiler.html"/><content type="text">在上一篇文章中，我主要表达了这样一个观点：影响程序效率的关键之一是算法，而算法的选择与优化，和是否多一个赋值少一个判断的关系不大。关于算法的选择，我谈到其理论上的复杂度，并不直接反映出效率。因为在实际运用时，数据的规模，形式等等都会涉及到算法的实际效用。一个时间复杂度低的算法并不代表任何情况下的效率都高。这是“实际”和“理论”的区别之一。现在我打算来谈一下另一个比较“实际”的东西：编译器对于程序效率的影响。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2009/12/25/my-view-of-il-4-how-to-learn-il.html</id><title type="text">老赵谈IL（4）：什么时候应该学IL，该怎么学IL</title><summary type="text">又是一个拖了半年的系列，可能是前几篇主要以事实为准，举例子的文章总是比较容易写的，因此十分顺畅。而最后一篇打算做一个总结，以讲道理为主——却发现该将的似乎都已经讲完了。不过做事要有始有终，该完成的也必须要完成。那么现在就来谈谈我的一些个人看法：什么时候应该学IL，以及应该怎么学IL。</summary><published>2009-12-24T16:08:00Z</published><updated>2009-12-24T16:08:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2009/12/25/my-view-of-il-4-how-to-learn-il.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2009/12/25/my-view-of-il-4-how-to-learn-il.html"/><content type="text">又是一个拖了半年的系列，可能是前几篇主要以事实为准，举例子的文章总是比较容易写的，因此十分顺畅。而最后一篇打算做一个总结，以讲道理为主——却发现该将的似乎都已经讲完了。不过做事要有始有终，该完成的也必须要完成。那么现在就来谈谈我的一些个人看法：什么时候应该学IL，以及应该怎么学IL。</content></entry><entry><id>http://www.cnblogs.com/JeffreyZhao/archive/2009/12/23/string-concat-perf-3-profiling-analysis.html</id><title type="text">重谈字符串连接性能（下）：分析优化</title><summary type="text">经过之间的性能比较，我们得知StringBuilder的性能并非时时最优，再经过实现分析，我们大致了解了StringBuilder的实现方式。虽然在此之前，大家也基本已经了解StringBuilder的实现原理，也有不少朋友指出了它性能缺陷的原因。不过“严谨”起见，寻找性能问题的方式应该是进行Profiling，然后找出性能关键再进行优化——而不是纯粹进行“阅读”这种静态分析方式。</summary><published>2009-12-23T06:03:00Z</published><updated>2009-12-23T06:03:00Z</updated><author><name>Jeffrey Zhao</name><uri>http://www.cnblogs.com/JeffreyZhao/</uri></author><link rel="alternate" href="http://www.cnblogs.com/JeffreyZhao/archive/2009/12/23/string-concat-perf-3-profiling-analysis.html"/><link rel="alternate" type="text/html" href="http://www.cnblogs.com/JeffreyZhao/archive/2009/12/23/string-concat-perf-3-profiling-analysis.html"/><content type="text">经过之间的性能比较，我们得知StringBuilder的性能并非时时最优，再经过实现分析，我们大致了解了StringBuilder的实现方式。虽然在此之前，大家也基本已经了解StringBuilder的实现原理，也有不少朋友指出了它性能缺陷的原因。不过“严谨”起见，寻找性能问题的方式应该是进行Profiling，然后找出性能关键再进行优化——而不是纯粹进行“阅读”这种静态分析方式。</content></entry></feed>
