我们列举了各种URL生成的方式，其中大致可以分为三类：直接拼接字符串（方法一及方法二）使用Route规则生成URL（方法三）使用Lambda表达式生成URL（方法四及方法五）我们可以轻易得知，这3种作法可维护性依次增加，而性能依次减少。不过，我们还是有一个疑问，这个性能究竟相差多少？它是否的确真的可以被忽略？为此，我们还是来进行一次性能对比吧。测试对象为了获得贴近实际的测试结果，我打算以我的博客首页作为测试对象。您可以发现，这个页面上的链接非常多，我把它分为三个部分：文章（Post）列表：... 阅读全文

经过之间的性能比较，我们得知StringBuilder的性能并非时时最优，再经过实现分析，我们大致了解了StringBuilder的实现方式。虽然在此之前，大家也基本已经了解StringBuilder的实现原理，也有不少朋友指出了它性能缺陷的原因。不过“严谨”起见，寻找性能问题的方式应该是进行Profiling，然后找出性能关键再进行优化——而不是纯粹进行“阅读”这种静态分析方式。那么，假设我们还是使用原来的方式使用StringBuilder连接字符串：static void Main()... 阅读全文

根据上次的评测结果，我们了解了几种字符串拼接方式的性能高低。从中可以看出，广受追捧的StringBuilder性能似乎并不是最好的，String.Concat方法有时候有时候更适合使用。那么为什么String.Concat方法性能那么高，StringBuilder又为什么落败，而我们又有没有什么可以改进的做法呢？为此，我们不妨动用.NETReflector这一利器，看一下两者是怎么实现的。String.Concat为什么这么快String.Concat方法有多个重载，其中我们关注那个接受字... 阅读全文

看到这个标题是不是觉得很奇怪呢？字符串连接的性能，这个话题已经被谈了一遍又一遍，一次又一次，似乎已成定论，这又有什么好谈的呢？不过说来奇怪，根据我的实验结果在网上进行搜索，却找不到答案。因此，我现在和大家一起重新再作一次实验并观察结果。在文章最后我也会给出完整的代码，您可以自由地运行，修改，尝试，我们再一起进行交流。说起字符串拼接，最简单的方式便是使用最普通的连接操作“+”，以及StringBuilder了。为此，我们准备一些测试代码：private static readonly str... 阅读全文

// 获取程序的基目录。 System.AppDomain.CurrentDomain.BaseDirectory // 获取模块的完整路径。 System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName // 获取和设置当前目录(该进程从中启动的目录)的完全限定目录。 System.Environment.CurrentDirectory // 获取应用程序的当前工作目录。 System.IO.D... 阅读全文

使用Monitor或Mutex进行同步控制的问题：由于独占访问模型不允许任何形式的并发访问，这样的效率总是不太高。许多时候，应用程序在访问资源时是进行读操作，写操作相对较少。为解决这一问题，C#提供了System.Threading.ReaderWriterLock类以适应多用户读/单用户写的场景。该类可实现以下功能：如果资源未被写操作锁定，那么任何线程都可对该资源进行读操作锁定，并且对读操作锁数量没有限制，即多个线程可同时对该资源进行读操作锁定，以读取数据。如果资源未被添加任何读或写操作... 阅读全文

一.File類別與FileInfo類別:使用File類別進行檔案操作時，每次都會進行安全性檢查。FileInfo類別則只會於第一次進行安全性檢查，如果你需重複使用物件好幾次，請考慮使用 FileInfo 的執行個體方法，以取代 File 類別的對應靜態 (Static) 方法，因為安全性檢查並不一定會需要。二.指定路徑:C#語言下路徑指定方式有兩種:是使用兩個斜線，例如 “C:\Test.txt”第二種是在路徑前加上@符號，例如 @”C:Test.txt”三.FileInfo的檔案操作EX... 阅读全文