: 我是使用宣告二维的 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