4 ms·
Basic CS fail. Most translation units have maybe 100 header files or fewer. While a hash map might be O(1) (O(n^2) worst case) and a linked list O(n^2), the ov
by bregma 4y ago
Basic CS fail.
Most translation units have maybe 100 header files or fewer. While a hash map might be O(1) (O(n^2) worst case) and a linked list O(n^2), the overhead of every insertion into a hash map is significantly greater than into a linked list. If you have such a tiny n, a linked list is almost always more time- and space-efficient. Switching to a more inappropriate data structure is more likely to negatively impact the performance of your toolchain.
Of course the best answer is to make the change and collect measurements before and after using a spectrum of data sets, then compare. Don't let me stop you. But remember for that small a number of items bubble sort is usually the fastest, most efficient algorithm. Also remember that looking up a header name at preprocessor time, no matter how slow, will likely not show up on your profile graph when you turn on the optimizer.
- LadyCailin 4y agoI’m pretty sure I read something on HN the other day that showed that a linked list is almost always a bad choice, even for small values, due to memory locality issues.
- deleted 4y ago[deleted]
- colejohnson66 4y agoRegardless of what’s better, my comment was more about how they have a profiled and optimized method for include guards, but threw it all away for #pragma once. If performance doesn’t matter because the optimizer is worse, then why’d they optimize include guards? My whole point is that something is not adding up with gcc’s implementation. It’s a fail on the authors’ parts, not mine.