Coding is hard, you can make it easy!

回首 2021

2021 年真是又忙又累的一年，一直在加班，清明加，五一加，周末更别提了。一直忙到年底，才真正休息了几天。2021 真的是在忙碌中度过的，好在努力没有白费，付出了不少，也收获了很多：

• 交付的项目得到了客户的认可。
• 我们的团队在不断壮大成长。
• 我们的工作流程在持续优化中。
• 我们的技术交流依旧在持续举办中。
• 我们开始 code review 啦。
• 我们开始全面拥抱 git 啦。

前言

前两篇文章 part1 和 part2 基本上理清了 IsSplitter() 运行缓慢的原因 —— 在函数内部使用了带 Compile 选项的正则表达式。

但是没想到在 IsSplitter() 内部使用不带 Compiled 选项的正则表达式，整个程序运行起来非常快，跟静态函数版本的运行速度不相上下。又有了如下疑问：

1. 为什么使用不带 Compiled 选项实例化的 Regex 速度会这么快？
2. 为什么把 Regex 变量从局部改成全局变量后运行速度有了极大提升？除了避免重复实例化，还有哪些提升？
3. 为什么 PerfView 收集到的采样数据，大部分发生在 MatchCollections.Count 内部，极少发生在 Regex 的构造函数内部？（使用带 Compiled 选项的正则表达式的时候）
4. Regex.IsMatch() 是如何使用缓存的？
5. 直接实例化的 Regex 对象会使用正则表达式引擎内部的缓存吗？
6. 正则表达式引擎内部根据什么缓存的？
7. 什么时候会生成动态方法？生成的动态方法是在哪里调用的？

本文会继续使用 Perfview 抓取一些关键数据进行分析，有些疑问需要到 .NET 源码中寻找答案。在查看代码的过程中，发现有些逻辑单纯看源码不太容易理解，于是又调试跟踪了 .NET 中正则表达式相关源码。由于篇幅原因，本篇不会介绍如何下载 .NET 源码，如何调试 .NET 源码的方法。但是会单独写一篇简单的介绍文章 。

前言

我在上一篇文章《记一次 .NET 程序的性能优化实战（1）—— 使用 process explorer 快速定位问题代码》中用 process explorer 定位到了导致程序运行缓慢的原因——使用了 .NET 中的正则表达式。.NET 中的正则表达式真这么慢吗？带着疑问，开始了本次的探索之旅。喜欢刨根问底的小伙伴儿快来一起看看吧！

前言

在前面两篇文章 记一次曲折的多资源文件拆分折腾过程（1） 和 记一次曲折的多资源文件拆分折腾过程（2） 中，已经把折腾过程中遇到的问题都弄清楚了。因为对这个问题印象太深刻了，而且 git 又是开源的，于是特地翻看了 git 的源码，并且在 windows 上用 gdb 简单调试了一波。

说明： 本篇文章适合 geek 阅读，全是一些源码查看及编译环境+调试的总结。

前言

本篇是上篇文章—— 记一次曲折的多资源文件拆分折腾过程（1） 的续篇。在上篇文章找到了导致编译报错的根本原因是 .rc 文件的编码不再是默认的 UTF-16LE-BOM 了。但是为什么 .rc 文件的编码会发生变化，并没有深究。本文继续探究一下。

缘起

最近这些天，我一有时间就捣鼓 .rc 。用 git 管理过 .rc 文件的小伙伴儿应该都知道，.rc 文件会被 git 默认当作二进制文件来管理。每次合并代码的时候，只要涉及到 .rc 文件的变更，很大概率会报冲突，而且工具不能很好的解决，只能手动解决。为了解决这个问题，我想到了两个方案：

1. 让 git 把 .rc 文件当成普通文件来管理。
2. 把一个大的 .rc 文件拆成多个小的 .rc 文件，这样可以有效的降低冲突的概率。

这两个方案相互之间没有任何冲突，所以这次折腾的时候，这两个方案是同时进行的。本以为没什么值得写的，没想到收获了意外惊喜，于是有了本篇总结。

缘起

因为需要分析 tfs 提交日志，并按照一定条件（比如，提交信息或者用户名）分类整理，特意写了这个小工具。在使用过程中发现，某些情况下会花费很长时间才能返回处理结果，当时稍稍做了一些优化，已经能满足当时的应用场景了。但是在处理大文件的时候依然会花费很长时间。忍了这么久了，终于有机会做一次效率优化了。

缘起

目前开发是在华为云桌面里进行的，在远端机器上装了 v15.05 版（很老的版本了）的 process explorer。但是今天打开 process explorer 后，Process Name 列消失不见了。

缘起

前一段时间，想使用 .net 监听特定文件夹中的文件是否发生变化。网上一搜，可以使用 .net 官方提供的 FileSystemWatcher，很开心的写好了代码。随着使用的不断深入，发现了 FileSystemWatcher 几个不够完善的地方。比如，

1. 事件触发时，文件可能还不能被访问。
2. 如果监听选项设置的过多，则有可能会触发多次文件变化事件。
3. 监听过滤器不够灵活，我没找到同时监听多种特定文件类型的方法。比如，同时只监听 .docx 和 .bmp 文件。

鉴于此，基于 .net 官方提供的 FileSystemWatcher，我又封装了一个新的类。可以在一定程度上解决以上几个问题。

前言

前几天，同事在 .net 程序中，遇到一个很 “诡异” 的问题：明明两个值是相等的，可偏偏却不相等，这是怎么回事呢？