0

我定义了以下查找表：

boost::unordered_map<std::string, STFRandomTreeFunctor*> functor_look_up_table;

这个想法是用它来调用函子，但这似乎运行得很慢。一开始我以为是functor调用的函数可能运行时间长，我把代码替换为如下（即去掉了对 的调用functor()）：

my_function(){
    while(...){
        STFRandomFunctor* f = functor_look_up_table.at(some_string);
        ...<do some other stuff>
    }
}

而且它仍然运行缓慢，删除该行STFRandomFunctor* f = functor_look_up_table.at(some_string);极大地加快了代码速度。我在这里的查找表中使用了错误的数据结构吗？如果是这样，什么是可取的？

4

2 回答 2

4

@aleguna 字符串是函数的 id，一些示例是“single_channel_subtract_abs”、“multi_channel_random_add”、“multi_channel_random_subtract_abs”。总共有5把钥匙

那么你不应该使用字符串，也不应该使用unordered_map：

// Function.hpp

enum FunctorName {
    single_channel_subtract_abs,
    multi_channel_random_add,
    multi_channel_random_substract_abs,
    ...
};

STFRandomTreeFunctor const& get(FunctorName name);

// Function.cpp
static STFRandomTreeFunctor const Functors[] = {
    ...
};

STFRandomTreeFunctor const& get(FunctorName name) {
    size_t const index = name;

    assert(index < sizeof(Functors) && "Need to update Functors");

    return Functors[index];
} // get

如果是一个函数类型而不是一个完整的函子，你可以完全放弃const&。getSTFRandomTreeFunctortypedef

于 2012-10-31T17:12:14.990 回答
0

unordered_map查找速度非常快，但是如果你有一个好的散列函数，每次你看你的地图时，你的键的散列都会被计算出来，所以如果计算散列需要很长时间，那么你的性能就会很差，另一方面如果hash函数生成相似hash的值可能所有（或很多）项目都落在一个桶中，然后你的搜索变成线性的，对于第一部分，你的字符串必须非常大到boost需要很长时间的默认散列，但对于第二部分，请尝试更改存储桶大小并再次检查性能。

于 2012-10-31T16:53:25.627 回答