Coding is hard, you can make it easy!

前言

在 上一篇文章 中，我们总结了使用 windbg 和 IDA 找出 cvtres.exe 报错的根本原因，但是留下了几个细节问题。本篇文章就来把这几个细节问题“格”干净。

缘起

前一段时间在折腾拆分 rc 的问题，已经把遇到的问题整理成文了。感兴趣的小伙伴儿可以参考这里，这里 和 这里。本以为不会有问题了，后续流程就请其它同事帮忙处理了，没想到在拆分实际项目时遇到了一个非常奇怪的链接问题。

本文总结了使用 process monitor 监听进程创建，查看进程参数、使用 gflags 设置 Image File Excution Options、使用 IDA 静态分析相关函数的业务逻辑以及使用 windbg 进行动态调试的整个过程。我认为这是一个由不良的编程习惯与 crt 的限制共同导致的问题。快来一起看看吧。

前言

在前面三篇文章中应该已经把 .NET 中正则表达式相关的问题”格尽”了。感兴趣的小伙伴儿可以参考 part1，part2 和 part3。

由于篇幅原因，在前面的文章中并没有介绍如何下载 .NET 源码，如何调试 .NET 源码。本文会简单介绍如何下载 .NET 源码，如何在线浏览 .NET 源码，如何使用 vs 调试 .NET 源码。

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