在解LeetCode上面關於DP or BFS/DFS的時候常會用到下面幾行code
vector<vector<int>> dirs{{0,-1}, {0,1}, {1,0}, {-1,0}};
func()
{
for(auto& dir: dirs)
{
int nr = r + dir[0];
int nc = c + dir[1];
}
}
for那一行有時候想說沒改到dir得值，就直接寫成for(auto dir: dirs)
沒想到leetcode算效能的時候結果差很多
我試過有時候從70%掉到10%
甚至超過時間submit failed
這兩種寫法真的有差這麼多嗎?

pass by reference當然有差 不是只傳一個int 是vector

auto& -> vector<int>&auto -> vector<int>一個傳reference 沒啥開銷

我比較喜歡DIRS{0,1,0,-1,0} LEN=4

同樓上

我記得傳 reference 會造成沒辦法把值放到 register，導致有時候 pass by value 反而會讓函數跑比較快但這個 case 傳 ref 應該是比較好啦...

寫auto&&會更好,免得當dirs的容器變成vector<bool>這種proxy class(會讓dereference得到一個暫時物件)使得lvalue-reference無法bind to it.

plain struct可能就還好 你這是複製vector所以效能影響比較大

沒改到就加 const

DIRS{0,1,0,-1,0} LEN=4 怎麼寫啊， len=5?

這個不重要 重要的是你的演算法而且compiler對於built-in type的東西有最佳化 pass byvalue的效能會更好 但不重要 演算法不是要考語言特性

我都用 const auto &var

@peter98 說是這樣說，但刷 LeetCode 的人有高比例都不只是為了測試演算法，多學一點語言特性都不會是壞事XD而且這年頭演算法別說語言特性了，連硬體特性都要考慮，已經不太純了XD

這個哪裡不重要 這是超級基本的C++特性

int x = i + dir[d], y = j + dir[d + 1];

這讓我想到我某同事把其他語言寫的算法直接搬到c++結果更慢就罵c++落伍又沒用 XD

高頻交易表示硬體才是問題

對語法熟、對編譯過程熟、對指令熟、對硬體特性熟，想拼到極致單靠演算法是不夠的寫嵌入式慢慢的 12MHz 可能還要精算每道指令的 cycle數咧，哪有什麼哪個東西不重要這種說法

而且也可能是 leetcode 的問題，有時候會發生同一份 code多 submit 幾次，每次跑出來效能都不一樣啊我的意思是發生效能不如預期也可能是 lc 的鍋，雖然這個 case 是因為 deep copying vectors 造成的

有人知道 constexpr等等compile time會不會算進作答時間嗎

應該不會 你拿meta programming玩一下No.509就知道了

不是template就不需要用auto&&了，因為你很清楚知道操作的iterator dereference之後的型別是不是proxy，如果是proxy還不如直接pass by value享受compiler對build-in type有可能給出的優化。寫template時你才會有考慮iterator dereference之後返回值的各種可能性問題。

dir這個用vector太浪費 建議直接用constexpr

純粹是lc 那個時間變化很大而已 你同一份多傳幾次 不同月份傳 結果可能出乎你意料