那種預測機制也不明白，只能舉個應用場合的例子，當一個數不斷自加直到被上限擋住為止，這個過程預測出錯只會出現在最開始和結尾，中間一直是否，預測起來不會出錯。

    更深的地方就挖不動了，先這樣。

    如何更快？硬件多數時間都在做加減乘除，再幹活，而不是把過多時間浪費在跑來跑去。

    增加限制條件，然後去掉冗餘的限制條件。

    放東西就是這個道理，越常用的越要放在能快速拿的地方。我們的世界不是遊戲裏抽象的倉庫，而是具有一個存儲的層次結構，有遠近難易之分。

    有記憶的統計來自於局部性，它認為已有之事後必再有，已行之事後必再行。我之前覺得有道理，後來覺得也未必，有些東西摒棄掉了就是摒棄掉了，可能會在別的個體上持續發生，但在單個個體上未必。這有點算是抬槓了，總之呢，局部性可以大大提高性能。

    無條件跳躍可能導致死循環啊，或者莫名其妙鬼畜起來了。雖然對於複雜的過程來說，未知錯誤是難免的，但還是儘可能把會出錯的地方修補一番，然後在關鍵的地方用try與catch。

    映射表的查找方法，如果虛擬內存和物理內存之間的映射表的查詢方式是順序查找，映射表又很長，查的位置不滿足局部性來回跳，那時間就會花費很多，這麼大的宏觀的事可能不是我該考慮的，我就把他縮小吧。要是我建立一個用於存儲和查詢的表，我就會儘量讓他們的序號有一定的意義，至少可以讓我或者程序估計，要查的東西在前一半還是在後一半，哦我想起來了，這是不是設計了主鍵的排序呢？我真是笨蛋。

    除了排序也可以分級，手動地告訴代碼，要找的東西在上一半還是下一半，分兩級就更加好找了。（過於幼稚）

    層之間的關鍵字可以用門電路連接，這樣的話很客觀安全，但是是犧牲了物理空間換去來速度傷的性能。沒有兩全法的。只有取捨。

    借用必須要有借用恢復，有點像中斷。

    需要保持狀態的塊，還是很經典的一句話，出門要有鎖存，進門要有緩衝。

    去掉冗餘，相同的部分只寫一次，這就是C++的優勢哦，不，是共享的優勢。

    創建一個垃圾堆，或者垃圾堆也可以臨時使用，多想想如何把現實中的概念應用到虛擬的領域，這樣或許我們分不清夢境與現實之前，就已經分不清虛擬與現實了。

    大塊與碎片的概念也很好，整可以碎，碎不可以整也。

    相鄰的塊要比破碎的塊更好用，不相鄰就要花費一部分出來連接破碎的塊，可能也需要花時間挑選出合適或足夠的塊們。

    &有和沒有區別很大，需要重視。

    顯示地初始化為0十分重要，要注意。

    動作的前面都會加入一個隱含的形容詞，請求。

    知其然容易，知其所以然難。我知前者少，知後者更少，怎麼會說話呢？不好意思啦。

    雖然看不懂的多，但還是有收穫的，加油！

    或許會二刷吧。或許。