我的问题是

是否有任何正则表达式引擎在正则表达式模式解析期间进行即时编译并在匹配/替换文本时使用？或者我在哪里可以学习 i386 或 x64 架构的 JIT？

为什么我需要它

我最近尝试将 Python 的内置正则表达式引擎与具有大约 10MB 数据的普通 C 代码进行比较。

我发现对于直接替换（例如abto zzz），它相对较快：仅比 C 慢 2 到 3 倍。

但是因为[a-z]c它花费的时间大约是 C 的 5 到 8 倍。

通过分组（例如([a-z])(c)to AA\2\1BB），它花费的时间是 C 的 20 到 40 倍。

它还不是即时编译，但我认为，如果我可以进行即时编译，它可以加快很多。

PS：我在编译模式时对每个正则表达式模式使用分析，例如，profile 1 用于简单的 like ab，profile 2 用于 range [a-z]c，profile 3 与 grouping ([a-z])(c)，每个配置文件都有单独的代码，因此在匹配和替换简单模式时不需要额外的成本.

更新 1

我已经用 psyco 试过了，它并没有提高速度。可能是因为我正在对大数据进行文本替换，而不是循环多次。

如果我没记错的话，re.sub我认为 Python 已经在本地运行它，所以 pysco 无法提高速度。

更新 2

我曾尝试将 boost 正则表达式封装到 python 中，但它甚至比 Python 的正则表达式还要慢，所以瓶颈似乎在于 Python 的字符串处理，Jan Goyvaerts 在答案中也指出了这一点。

更新

我想将正则表达式模式转换ab[a-z]c为机器代码，如以下等效 C 代码（*s指向 10MB 长文本）：

有任何想法吗？

在我们的 Java 环境中，我们似乎遇到了一个奇怪的错误。我们现在已经发生了两次相同的“不可能发生”异常；在一个案例中，问题在运行过程中的 48 分钟内发生了 42,551 次，然后自发地自行解决。

失败的代码由这一行触发：

在哪里int source = 0和long quoteID = 44386874（例如）。

例外是：

检查代码'd'不应引发此异常。

我们想出的最好的解释是 JIT 编译器生成了错误的字节码，但在随后的重新 JIT 中它编写了好的代码。

任何人都有解决/诊断此类问题的方法的经验吗？

罗杰。

你知道类似这样的东西，但可以嵌入到 C 程序中吗？

我已经使用 llvm.org 上的在线编译器生成了一个 bc 文件，我想知道是否可以从 ac 或 c++ 程序加载此 bc 文件，使用 llvm jit 执行 bc 文件中的 IR（以编程方式在c程序），并得到结果。

我怎样才能做到这一点？

通过反射加载的类中代码的执行时间（运行时）性能是否与使用 new 关键字创建类时的相同代码相同？

我说是。但我正在与一位认为面向反射的代码总是较慢的同事讨论这个问题。

我的观点是，无论类最初是如何加载/创建的，性能都是相同的，因为 JIT 编译器并不关心类是如何加载的。

我对么？无论哪种方式，我都会感谢任何可以帮助澄清这一点的参考资料。

（注意：我不是在谈论使用反射与 new 关键字创建类的性能。我指的是类创建后方法中的实际代码。）

是否可以在运行时操纵（签名的）.NET 程序的字节码？例如，通过强制 JIT 重新评估 IL？

我听说 Java 必须使用 JIT 才能快。与解释相比，这非常有意义，但为什么有人不能制作一个能够生成快速 Java 代码的提前编译器呢？我知道gcj，但我认为它的输出通常不会比 Hotspot 快。

语言有没有让这变得困难的事情？我认为归结为以下几点：

• 反射
• 类加载

我错过了什么？如果我避免使用这些功能，是否可以将 Java 代码一次编译为本机机器代码并完成？

我有以下 .NET 值类型：

我有将指向值类型的指针传递给非托管代码的代码，以及通过调用 System.Runtime.InteropServices.Marshal.OffsetOf 发现的偏移量。非托管代码正在填充 Date 和 double 值。

为 StringPair 结构报告的偏移量正是我所期望的：0、8、16、24、32

我在测试函数中有以下代码：

哪个打印出这些偏移量。

然后我有一些测试代码： foreach (StringPair pair in pairs) { Date d = pair.D; 双 v = 对.V; ...

在调试器中具有以下与之关联的汇编程序：

它在偏移量 32 (0x20) 处加载 D 字段，在偏移量 24 (0x38-0x20) 处加载 V 字段。JIT 改变了顺序。Visual Studio 调试器也显示了这种倒序。

为什么！？我一直在拔头发，试图看看我的逻辑哪里出了问题。如果我在结构中交换 D 和 V 的顺序，那么一切正常，但是此代码需要能够处理其他开发人员定义了结构的插件架构，并且不能期望他们记住神秘的布局规则。

最近，我在使用 .NET 3.5 开发的应用程序之一中观察到以下有趣的场景。在这个特别的应用程序中，我有一个单独的对象，我将其作为静态变量访问。我预计 .NET 运行时应该在我第一次访问它时初始化这个单例对象，但似乎情况并非如此。.NET 运行时在我访问这个特定对象之前对其进行初始化。以下是一些伪代码，

即使在运行时，我的代码也只执行 if 语句中的代码。NET 运行时仍然初始化单例对象。在某些应用程序运行中，我根本不需要访问这个特殊对象！

此外，我在调试版本中看不到这种行为。似乎这与优化构建（发布构建）有关。

这是 .NET 运行时的预期行为吗？

更新：

以下是实际代码，

即使我的应用程序不执行 else if 阻止类 MOSSStateHandler 初始化的代码。

在对此答案的评论中（建议在整数乘法/除法上使用位移运算符，以提高性能），我质疑这实际上是否会更快。在我的脑海里有一个想法，在某种程度上，有些东西会足够聪明，可以解决这个问题，>> 1并且/ 2是相同的操作。但是，我现在想知道这是否真的是真的，如果是的话，它发生在什么级别。

optimize测试程序为分别划分和移动其参数的两种方法生成以下比较 CIL (with on)：

相对

所以 C# 编译器是在发出div指令shr，而不是聪明。我现在想看看 JITter 生成的实际 x86 汇编程序，但我不知道如何执行此操作。甚至可能吗？

编辑添加

发现

感谢您的回答，已接受来自 nobugz 的回答，因为它包含有关该调试器选项的关键信息。最终对我有用的是：

• 切换到发布配置
• 在Tools | Options | Debugger中，关闭“Suppress JIT optimization on module load”（即我们要允许JIT 优化）
• 同一个地方，关闭“仅启用我的代码”（即我们要调试所有代码）
• 在Debugger.Break()某处发表声明
• 构建程序集
• 运行 .exe，当它中断时，使用现有的 VS 实例进行调试
• 现在 Disassembly 窗口显示了将要执行的实际 x86

结果至少可以说是很有启发性的——事实证明 JITter 实际上可以做算术！这是来自“反汇编”窗口的编辑示例。各种-Shifter方法除以二的幂使用>>；各种-Divider方法除以整数使用/

两种静态除以 2 方法不仅被内联，而且实际计算已经由 JITter 完成

与静态除以 3 相同。

并静态除以 4。

最好的：

它是内联的，然后计算所有这些静态除法！

但是如果结果不是静态的呢？我添加了代码以从控制台读取整数。这就是它为以下部门产生的结果：

因此，尽管 CIL 不同，但 JITter 知道除以 2 是右移 1。

00000283 idiv eax,ecx

它知道你必须除以 3。

它知道除以 4 就是右移 2。

终于（又是最好的了！）

它根据静态可用的参数内联了方法并找出了做事的最佳方式。好的。

所以是的，在 C# 和 x86 之间的堆栈中的某个地方，有一些足够聪明的东西可以解决这个问题>> 1并且/ 2是相同的。所有这一切都让我更加重视我的观点，即把 C# 编译器、JITter 和 CLR 加在一起比我们作为谦逊的应用程序程序员可以尝试的任何小技巧更聪明:)