unordered_set與鏈表查找之間的性能比較

Question

我正在將C文件轉換為C ++。 由於仍將通過C代碼調用這些函數，因此我將整個文件放在extern“ C”塊中。 該文件包含以下代碼-

struct node{
    char* name;
    struct node* next;
};

static struct node* list;  //file scope

void insertInList(FILE*){
    read file line-by-line and add names present in file to the list
}
bool isNamePresent(char* name){
    //iterate through Linked-list & returnt true if present
}

現在，在我看來，可以通過使用unordered_set來提高'isNamePresent'的復雜性。 但是，從客戶使用情況來看，列表中通常輸入的名稱很少（有時只有1個）。

Q1）因此，我是否仍應更改代碼以使用unordered_set？ 在性能或其他任何方面是否仍被認為是一個很好的變化？如果是，請解釋原因？？ 另外，在我們知道一般使用模式時，是否在軟件開發過程中考慮了“如果用戶在文件中輸入十萬個名稱該怎么辦”這樣的場景？

Q2）我應該如何在文件中寫集？ 在全局空間中寫的以下幾行之間有什么區別？

static std::unordered_set<std::string> st;
vs 
namespace{
    static std::unordered_set<std::string> st;
}//anonymous namespace

第一個是否用一些垃圾值初始化了？

Answer 1

通常，真正了解哪種方法在您的應用程序場景中效果最好的唯一方法是評估每種方法在您的應用程序場景中的性能。 話雖這么說，我只會選擇unordered_set 。 我這樣做的主要原因是可讀性。 unordered_set<string>非常清楚地傳達了您在這里所做的事情：存儲一堆字符串以便跟蹤一組元素並有效地檢查給定的字符串是否屬於該元素集（因為這是您唯一可以做的事情）確實使用unordered_set ）。 另一方面，鏈表可用於許多目的，實現的集合不是很常見。 必須從使用列表的方式推斷出該列表的用途。

此外，雖然unordered_set不一定是人們可以想象的最有效的哈希表，但還不算太糟，搜索鏈接列表很可能會更糟。 在某些情況下，當只有幾個項目時，在諸如std::vector類的連續容器中進行線性搜索可能會帶來性能上的優勢，但之所以這樣做，是因為在連續的內存中進行迭代非常有效在現代處理器上。 鏈表通常不是連續的。 即使列表項碰巧是以連續方式分配的，與通過純vector進行迭代相比，仍然存在內存和運行時開銷。 鏈表相對於std::vector的主要優點在於，該列表支持O（1）時間復雜度的隨機插入，並且如果列表被修改，則指向列表項的指針仍然有效。 這些屬性似乎都與您的情況無關。 unordered_set還具有O（1）平均插入時間復雜度。 並且它具有O（1）平均查找時間復雜度（與列表的O（n）比較）。 雖然在unordered_set查找通常將涉及一些間接尋址，但是在鏈表中的查找幾乎肯定會涉及更多的間接尋址。

因此，如果要在此處選擇，則選擇應該最有可能在std::unordered_set和std::vector 。 除非您真的需要其中一個屬性，否則只有鏈表才能給您（例如，修改容器時指向項目的指針保持有效；但是，在這種情況下，您可能還需要考慮使用std::set而不是鏈表） ）。 如果您不這樣做，我將使用std::unordered_set 。 如果性能真的很關鍵（到目前為止，很可能沒有給出一個簡單的鏈表似乎效果很好）：測量，比較，分析…

關於第二個問題：兩者之間沒有真正的區別

static std::unordered_set<std::string> st;

和

namespace {
    std::unordered_set<std::string> st;
}

這只是使事物具有內部聯系的兩種不同方式。 在C ++中，我將使用未命名的命名空間（注意：如果您已經在使用未命名的命名空間，則不需要static ），因為它看起來更像C ++。 static通常用於制作靜態局部變量和成員變量； static這種特殊用法（用於使具有內部鏈接的全局變量）主要用於實現C兼容性…