加快 StreamReader 的搜索/读取速度答案

【问题标题】：Speed up searching/reading from StreamReader加快 StreamReader 的搜索/读取速度
【发布时间】：2014-05-22 06:12:17
【问题描述】：

我正在尝试下载 FTP 服务器中存在的文件名列表，一旦我检索到所有名称，我将使用 StreamReader 对象并尝试搜索所有文件名以检查任何文件包含的子字符串是否存在存在于该 ftp 中。

例如，如果文件名是这样的

0000730970-0633788104-20140422073022-0633788104.PDF

0000730970-0633789720-20140422101011-0633789720.PDF

0000730970-0633798535-20140425075011-0633798535.PDF

0000730970-0633798536-20140425075011-0633798536.PDF

0000730970-0633804266-20140428124147-0633804266.PDF

0000730970-0633805880-20140429065011-0633805880.PDF

我将搜索“0633798535”（用破折号分隔的第二个或最后一个子字符串，因为这是我拥有的关于该 ftp 中存在的那些文件的唯一信息，不知道完整的文件名）。下面是我用来执行此操作的代码

try{
browseRequest = (FtpWebRequest)FtpWebRequest.Create(ftpAddress);

browseRequest.Credentials = new NetworkCredential(username, password);
browseRequest.UsePassive = true;
browseRequest.UseBinary = true;
browseRequest.KeepAlive = true;

browseRequest.Method = WebRequestMethods.Ftp.ListDirectory;
response = (FtpWebResponse)browseRequest.GetResponse();
responseStream = response.GetResponseStream();

if (responseStream != null)
{
    using (StreamReader reader = new StreamReader(responseStream))
    {
        while (!reader.EndOfStream && !isDownloaded)
        {
            string fileName = reader.ReadLine().ToString();
            if (fileName.Contains(subStringToBeFind)) //search for the first encounter
            {
                //download the file
                isDownloaded = true; //initially false
            }
        }
    }
}
}

这里我使用顺序搜索来查找文件名。但问题是，如果文件的数量很大，搜索就会变慢，比如 82000 个文件名，如果我正在寻找最后一个文件，搜索需要 2 分钟。因此，应用程序很慢。所以，我需要帮助来加速搜索。有什么方法可以使用二分搜索或其他方法来提高搜索时间。

【问题讨论】：

如果您的搜索空间已排序，您只能使用二进制搜索，因此除非您以排序顺序从服务器上获取文件，否则这可能不会超过线性搜索（因为排序的成本将占主导地位）。简单的事实是处理 82000 ftp 文件名会有点慢。你的程序需要 2 分钟有关系吗？您是否有以用户为中心的速度目标？
@dlev 确实也是以用户为中心的速度目标。因为之前整个过程都是手动的（打开ftp找到需要的文件下载它然后再次使用adobe acrobate或其他东西将它与另一个pdf合并，这些都需要时间）现在要求是自动以节省时间。

标签： c# search streamreader ftpwebrequest

【解决方案1】：

只有当您已经拥有所有数据时才能使用二分搜索（并且如果它已排序，看起来可能就在这里）。我强烈怀疑瓶颈不是这里的Contains 方法——我希望它是数据传输。这看起来已经相当有效了，尽管我会做出三个改变：

使用ReadLine()在输入结束时返回null这一事实，而不是使用EndOfStream
使用 ReadLine() 声明返回 string 的事实 - 您无需调用 ToString。（这不会影响你的表现，但它很难看。）
对响应和响应流使用using 语句。您可能没问题，因为您为读者准备了一个 using 声明，但您应该至少为响应本身提供一个声明。

所以：

string line;
while (!isDownloaded && (line = reader.ReadLine()) != null)
{
    if (line.Contains(target))
    {
        isDownloaded = true;
    }
}

要验证问题确实是 network 而不是 Contains 调用，请尝试将两者分开（仅用于诊断目的；您不想在现实中这样做，因为您希望能够在找到文件后立即停止）：

获取所有文件名，并将它们存储在文件中（或内存中）
搜索文件名

对两个步骤都计时 - 如果您没有发现第一步几乎所有时间，我会感到惊讶。使用 Contains 搜索 82000 个字符串应该非常非常快。

【讨论】：