F# 与 C# 性能签名及示例代码

Question

关于这个话题已经有很多讨论了，但我更喜欢鞭打死马，尤其是当我发现它们可能还在呼吸时。

我当时正在解析 CSV 这种不寻常且奇特的文件格式，为了好玩，我决定针对我所知道的 2 种 .net 语言（C# 和 F#）来描述其性能。

结果……令人不安。 F# 以很大优势赢得了 2 倍或更多（实际上我认为它更像是 0.5n，但事实证明获得真正的基准测试非常困难，因为我正在针对硬件 IO 进行测试）。

像读取 CSV 这样常见的事情中不同的性能特征令我感到惊讶（请注意，该系数意味着 C# 在非常小的文件上胜出。我做的测试越多，感觉 C# 的扩展性就越差，这既令人惊讶又令人担忧，因为这可能意味着我做错了）。

一些注意事项：Core 2 双核笔记本电脑，主轴磁盘 80 GB，3 GB DDR 800 内存，Windows 7 64 位高级版，.Net 4，未打开电源选项。

30,000 行 5 宽 1 短语 10 个字符或更少给了我 3 的因子，有利于第一次运行后的尾部调用递归（它似乎缓存了文件）

300,000（重复相同的数据）是尾部的 2 因子使用 F# 的可变实现进行调用递归稍微胜出，但性能签名表明我正在访问磁盘而不是对整个文件进行 ram 磁盘，这会导致半随机性能峰值。

F# 代码

//Module used to import data from an arbitrary CSV source
module CSVImport
open System.IO

//imports the data froma path into a list of strings and an associated value
let ImportData (path:string) : List<string []> = 

    //recursively rips through the file grabbing a line and adding it to the 
    let rec readline (reader:StreamReader) (lines:List<string []>) : List<string []> =
        let line = reader.ReadLine()
        match line with
        | null -> lines
        | _ -> readline reader  (line.Split(',')::lines)

    //grab a file and open it, then return the parsed data
    use chaosfile = new StreamReader(path)
    readline chaosfile []

//a recreation of the above function using a while loop
let ImportDataWhile (path:string) : list<string []> =
    use chaosfile = new StreamReader(path)
    //values ina loop construct must be mutable
    let mutable retval = []
    //loop
    while chaosfile.EndOfStream <> true do
        retval <- chaosfile.ReadLine().Split(',')::retval 
    //return retval by just declaring it
    retval

let CSVlines (path:string) : string seq= 
    seq { use streamreader = new StreamReader(path)
          while not streamreader.EndOfStream do
            yield streamreader.ReadLine() }

let ImportDataSeq (path:string) : string [] list =
    let mutable retval = []
    let sequencer = CSVlines path
    for line in sequencer do
        retval <- line.Split()::retval
    retval

C# 代码

using System;
using System.Collections.Generic;
using System.Linq;
using System.IO;
using System.Text;

namespace CSVparse
{
    public class CSVprocess
    {
        public static List<string[]> ImportDataC(string path)
        {
            List<string[]> retval = new List<string[]>();
            using(StreamReader readfile = new StreamReader(path))
            {
                string line = readfile.ReadLine();
                while (line != null)
                {
                    retval.Add(line.Split());
                    line = readfile.ReadLine();
                }
            } 

           return retval;
        }

        public static List<string[]> ImportDataReadLines(string path)
        {
            List<string[]> retval = new List<string[]>();
            IEnumerable<string> toparse = File.ReadLines(path);

            foreach (string split in toparse)
            {
                retval.Add(split.Split());
            }
            return retval;
        }
    }

}

请注意其中的各种实现。使用迭代器、使用序列、使用尾部调用优化、两种语言的 while 循环...

一个主要问题是我正在访问磁盘，因此可以解释一些特性，我打算重写此代码以读取内存流（假设我不开始交换，应该更加一致）

但是我所教/读的所有内容都表明 while 循环/for 循环比尾调用优化/递归更快，并且我运行的每个实际基准测试都在说与此完全相反。

所以我想我的问题是，我应该质疑传统智慧吗？

在 .net 生态系统中，尾调用递归真的比 while 循环更好吗？

这在 Mono 上效果如何？

Answer 1

我认为差异可能是由于 F# 和 C# 中不同的 List 引起的。 F# 使用单链表（请参阅 http://msdn.microsoft.com/en- us/library/dd233224.aspx），而在 C# 中使用的是基于数组的 System.Collections.Generic.List。

对于单链表来说，连接要快得多，特别是当您解析大文件时（您需要不时分配/复制整个数组列表）。

尝试在 C# 代码中使用 LinkedList，我对结果很好奇:) ...

PS：此外，这也是何时使用探查器的一个很好的示例。您可以轻松找到 C# 代码的“热点”...

编辑

因此，我自己尝试了这一点：我使用了两个相同的文件来防止缓存效应。这些文件有 3.000.000 行，包含 10 次“abcdef”，以逗号分隔。

主程序如下所示：（

static void Main(string[] args) {
   var dt = DateTime.Now;
   CSVprocess.ImportDataC("test.csv"); // C# implementation
   System.Console.WriteLine("Time {0}", DateTime.Now - dt);
   dt = DateTime.Now;
   CSVImport.ImportData("test1.csv"); // F# implementation
   System.Console.WriteLine("Time {0}", DateTime.Now - dt);
}

我也尝试过先执行 F# 实现，然后执行 C#...）

结果是：

• C#：3.7 秒
• F#：7.6 秒

运行 C# 解决方案之后 F# 解决方案为 F# 版本提供了相同的性能，但为 C# 提供了 4.7 秒（我认为是由于 F# 解决方案分配了大量内存）。单独运行每个解决方案不会改变上述结果。

对于 C# 解决方案，使用 6.000.000 行的文件大约需要 7 秒，F# 解决方案会产生 OutOfMemoryException（我在具有 12GB RAM 的机器上运行它......）

所以对我来说，传统的“智慧”似乎是这样的是的，C# 使用简单的循环对于此类任务来说速度更快......

Answer 2

您真的、真的、真的、真的不应该从这些结果中解读任何内容 - 要么对您的整个结果进行基准测试系统作为系统测试的一种形式，或者从基准测试中删除磁盘 I/O。这只会让事情变得混乱。采用 TextReader 参数而不是物理路径可能是更好的做法，以避免将实现链接到物理文件。

此外，作为微基准测试，您的测试还有一些其他缺陷：

• 您定义了许多在基准测试期间未调用的函数。您正在测试 ImportDataC 或 ImportDataReadLines 吗？为了清晰起见，进行选择 - 在实际应用程序中，不要重复实现，而是排除相似之处并根据另一个来定义一个。
• 您在 F# 中调用 .Split(',') 而在 C# 中调用 .Split() - 您打算按逗号还是空格进行拆分？
• 您正在重新发明轮子 - 至少将您的实现与使用高阶函数（又名 LINQ）的更短版本进行比较。

Answer 3

我注意到您的 F# 似乎正在使用 F# 列表，而 C# 正在使用 .Net 列表。可能会尝试更改 F# 以使用其他列表类型来获取更多数据。