: 我是使用宣告二維的 struct : struct 中再在宣告一二維陣列 : 最近陣列維度到了 1000*1000*10*10 10^8次 單位差不多是 百MB 如果你的元素是int 基本上也要400mb 如果是double或是long更是要800mb : 差不多有一億個值要去指派 : 陣列實作 效能明顯變嫚 : 宣告就要等好久 = = (~ 1 min) : 問題一 : : 想請教各位前輩有什麼比較好的儲存方法可以建議呢 ? 買多一點記憶體 最有效的方法... 其他的話....建議先... 想想看是不是這是必要的 一般應用很少有一定要這麼大空間才能實行的運算 能不能開小一點 也可以達到同樣的效果?? 真的要這麼大?? 改變運算流程方式 看能否不用需要這麼大的空間?? (演算法問題? dp改成其他?) 能不能分段算? 每個算完的結果都會用到嗎? 如果前面的結果用不到 一次算一部份 結果存在他處? 或是乾脆先放檔案裡 要用再去存取? 能否預知結果的範圍來選擇較小的元素 像是char或是short? 延伸上面 能否把幾個元素塞在一個元素裡頭 要用再拆解... 因為不知道你倒底是需要什麽運算 只能給你一點空間策略上的建議... 再來 如果你確定真的一定要這麼大的記憶體 ... 那就盡可能減少記憶體管理的額外負擔 像是C#或JAVA這種自動管理記憶體的程式 有其好處也有其壞處 其一就是記憶體管理的額外負擔 需要額外的空間來存放一些管理的資訊 每個物件 每個記憶體的配置區塊等等 都是管理的目標 所以你每次new一個陣列 這個陣列(物件)就加入管理對象 需要額外的記憶體來記錄這筆資訊 所以你...1000*1000*10*10 你自己算算產了多少個別物件(陣列)...這樣的額外負擔是 很大的 如果改成 10*10*1000*1000 額外負擔又是多少? 看起來一樣...但是... 如果每個大小10的陣列 要幾個咧...每個大小1000的陣列 又要幾個呢... 隨便算 前者大概是1000*1000*10 後者大概是 10*10*1000...有可能差到100倍... 假設你一個物件大小是10 額外管理空間是5 那就是5/10=50%的管理成本 如果你一個物件大小是1000 就是 5/1000=0.5% 另外 你可以甘脆用一個超大陣列 一維 大小就是 10^8 (記憶體不夠不能用這招) 然後所有位址的轉換都你自己做 例如 1000*1000*10*10 的話 4D[a][b][c][c]=1D[ a*1000*10*10 + b*10*10 + c*10 + d ] 這樣的話 管理的成本就幾乎降到0了 根本不算什麽 說了這麼多 就要看你的取決了 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.217.14