回首 2021
2021
年真是又忙又累的一年,一直在加班,清明加,五一加,周末更别提了。一直忙到年底,才真正休息了几天。2021
真的是在忙碌中度过的,好在努力没有白费,付出了不少,也收获了很多:
- 交付的项目得到了客户的认可。
- 我们的团队在不断壮大成长。
- 我们的工作流程在持续优化中。
- 我们的技术交流依旧在持续举办中。
- 我们开始
code review
啦。 - 我们开始全面拥抱
git
啦。
前两篇文章 part1 和 part2 基本上理清了 IsSplitter()
运行缓慢的原因 —— 在函数内部使用了带 Compile
选项的正则表达式。
但是没想到在 IsSplitter()
内部使用不带 Compiled
选项的正则表达式,整个程序运行起来非常快,跟静态函数版本的运行速度不相上下。又有了如下疑问:
Compiled
选项实例化的 Regex
速度会这么快?Regex
变量从局部改成全局变量后运行速度有了极大提升?除了避免重复实例化,还有哪些提升?PerfView
收集到的采样数据,大部分发生在 MatchCollections.Count
内部,极少发生在 Regex
的构造函数内部?(使用带 Compiled
选项的正则表达式的时候)Regex.IsMatch()
是如何使用缓存的?Regex
对象会使用正则表达式引擎内部的缓存吗?本文会继续使用 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
文件的编码会发生变化,并没有深究。本文继续探究一下。