【问题标题】:A scalable collection for large indeterminate dataset大型不确定数据集的可扩展集合
【发布时间】:2018-01-19 07:41:00
【问题描述】:

我有一个处理大型数据集的进程,处理Parallel.ForEach 中的记录,然后将结果存储在ConcurrentQueue<List<string>> 中。因此处理了一条记录,记录中的每个字段都会生成一个字符串,然后将其添加到List。在记录的末尾List 则为Enqueued,并在保存所有已处理记录的ConcurrentQueue 上进行进一步处理。

在处理该集合几个小时后,我注意到我的 CPU 使用率已经从新的一波上升到保持相当高的水平,并且处理一组记录的时间开始增加。

我在这里的假设是List 被填满,然后复制到一个新的更大的List 中。随着大小的增加,需要跟上此容量的 CPU,初始化周期也会增加。我正在使用的数据集大小不确定,因为每条记录都有可变数量的子记录。父记录的数量通常在 500k 左右。

所以我的第一个想法是将List初始化为父记录的Count。由于子记录,List 仍然必须增长,但至少必须增长更少的次数。但是,是否有其他集合替代 List 可以更好地扩展?还是比我的第一直觉更好的方法?

【问题讨论】:

    标签: c# scalability


    【解决方案1】:

    ConcurrentQueue 以链表的形式实现,不需要根据容量调整大小(与常规队列不同)。 所以你的问题将在其他地方。

    您可能需要查看已使用的内存量和清理已处理列表导致的垃圾收集率。

    其他提示:

    • 如果在从字段构造字符串时有很多字符串操作,请使用 Stringbuilder(如果您还没有这样做的话)。
    • 如果记录中有很多字段并且您有办法预先知道有多少:使用每个记录的数组而不是列表,或者将列表容量设置为可以容纳记录的所有字符串的值.

    【讨论】:

    • 很高兴了解 ConcurrentQueue。我将对字符串本身进行提示检查(这是我刚刚进入的代码库,因为它正在挣扎)。不过,列表上的容量设置肯定是可行的,因为字段计数在记录之间是静态的。
    • 在这种情况下,每条记录使用一个数组而不是一个列表(稍微快一点)
    猜你喜欢
    • 1970-01-01
    • 2014-11-15
    • 2015-12-11
    • 2013-08-25
    • 2016-06-20
    • 2019-03-30
    • 2020-12-16
    • 1970-01-01
    • 2014-10-01
    相关资源
    最近更新 更多