.net区段实际运行缓慢

问题描述

| 更新：安德鲁和康拉德的答案都同样有用。定时问题的简单解决方法解决了该问题，并且缓存了较大的对象引用，而不是每次都重新构建它们，这消除了问题的根源。谢谢大家的投入。我正在使用c＃.NET API，由于某种原因，以下代码执行我感觉非常极端/缓慢的代码。这是System.Timers.Timer的处理程序，该处理程序每5秒触发一次经过的事件。

private static void TimerGo(object source,System.Timers.ElapsedEventArgs e)
    {
        tagList = reader.GetData(); // This is a collection of 10 objects.

        storeData(tagList); // This calls the \'storeData\' method below

    }

和storeData方法：

private static void storeData(List<obj> tagList)
    {
        TimeSpan t = (DateTime.UtcNow - new DateTime(1970,1,1));
        long timestamp = (long)t.TotalSeconds;

        foreach (type object in tagList)
        {
            string file = @\"path\\to\\file\" + object.name + \".rrd\";

            RRD dbase = RRD.load(file);

            // Update rrd with current time timestamp and data.
            dbase.update(timestamp,new object[1] { tag.data });
        }
    }

我是否缺少一些明显的资源库？您看到的RRD内容来自rrawtool的NHawk C＃包装器；在这种情况下，我用它更新了10个不同的文件，但是我看不出它为什么需要这么长时间。当我说“那么长”时，是指计时器在第一次更新完成之前触发了第二次，因此最终“更新2”将在“更新1”之前发生，这会中断事情，因为“更新1”的时间戳早于“更新2”。我将计时器长度增加到10秒，并且运行了更长的时间，但最终还是超越了自己，并尝试使用更早的时间戳来更新文件。我可以做些什么来提高效率，因为显然我在做某件事严重错误。

解决方法

tagList中的每个标签是否都有不同的RRD文件？在伪代码中，每个文件打开N次。（您认为列表中只有10个对象。）然后执行更新。我只能假定您在更新RRD文件后将其处置。如果不这样做，您将保留对打开文件的引用。如果RRD是相同的，但是您只是将不同类型的绘图数据放入单个文件中，则只要您希望对其具有独占写入访问权限，就只需将其保持打开状态。在不分析代码的情况下，您有几种选择（我建议对btw进行分析）保持RRD文件打开缓存打开的文件以防止您不得不打开文件，每5秒关闭一次写入。只需缓存10个打开的文件引用，然后每5秒钟写入一次即可。将数据收集与数据写入分开似乎您每隔5秒从某个对象中获取度量标准样本。如果您的文件没有“定型”，则将集合与文字分开。提取数据样本并将其放入队列中进行处理。处理器将使每个tagList出队，并尽快写入，然后从队列中返回更多列表。这样，即使写入机制的速度变慢，也可以始终确保获得约5秒的样本。 , 并不能真正回答您的性能问题，但是如果您想解决租金问题，请将您的计时器设置为AutoRest为false，然后在方法末尾调用start（），例如

private static void TimerGo(object source,System.Timers.ElapsedEventArgs e)
{
    tagList = reader.GetData(); // This is a collection of 10 objects.

    storeData(tagList); // This calls the \'storeData\' method below
    timer.Start();
}

, 使用探查器。 JetBrains是我的个人推荐。用程序运行探查器，并寻找花费最长时间运行的线程/方法。这听起来很像是IO或数据问题，但是从您的示例代码中并不能立即看出来。

区段实际缓慢运行运行

.net区段实际运行缓慢

问题描述

解决方法

相关问答