JavaScript对象与最小效率

时间:2017-12-06 08:47:16

标签: javascript mongodb meteor minimongo

我的Meteor客户端从服务器接收数据并将其存储在minimongo中。保证这些数据在会话期间不会改变,因此我不需要Meteor的反应性。静态数据恰好通过该路线到达;让我们把它作为给定的。

数据如下所示:

{_id: 'abc...', val: {...}}

在客户端上,使用以下方式查找值是否更有效:

val_I_need = Collection.findOne({id})

或创建JavaScript对象:

data = {}
Collection.find().fetch().map((x) => {data[x._id] = x.val})

并将其用于查找:

val_I_need = data[id]

是否存在一个临界点,无论是数据大小还是查找次数,更有效的方法更改,还是超过构建对象的初始成本?

2 个答案:

答案 0 :(得分:1)

FindOne在更大的数据集上可能更有效,因为它使用游标查找_id是索引键,而find().fetch()方法需要获取所有文档,然后通过映射手动迭代

请注意,findOne也可以替换为.find({_id:desiredId}).fetch()[0](假设它返回所需的文档)。

mongo documentation on query performance中的更多内容。

但是,如果它只涉及一个后来没有被反应跟踪的对象,我宁愿通过服务器上的" findOne" -returning方法加载它:

export const getOne = new ValidatedMethod({
    name: "getOne",
    validate(query) {
        // validate query schema
        // ...
    },
    run(query) {

        // CHECK PERMISSIONS
        // ...

        return MyCollection.findOne(query);
});

这可以避免在当前客户端模板上使用发布/订阅,从而最小化此集合。想想pub / sub已经初始化了一些反应,以观察集合,从而在某处进行一些计算。

答案 1 :(得分:0)

我的直觉是,你永远不会达到将它放入物体的性能提升产生明显差异的程度。

您的瓶颈更可能出现在pub / sub机制中,因为将所有文档发送给客户端可能需要一段时间。

通过使用Meteor方法检索数据,您将看到大型数据集的显着差异。

无论如何,你已经在一个普通的旧javascript对象中获得了它,因此最终也获得了原生对象查找的小的性能提升。

相关问题