用冒号问号的句式做数据交换,是一种基于条件数据传送的手段。它有好有坏我不好掌握,但是,应该先好好习惯冒号问号的代码书写格式。
那种预测机制也不明白,只能举个应用场合的例子,当一个数不断自加直到被上限挡住为止,这个过程预测出错只会出现在最开始和结尾,中间一直是否,预测起来不会出错。
更深的地方就挖不动了,先这样。
如何更快?硬件多数时间都在做加减乘除,再干活,而不是把过多时间浪费在跑来跑去。
增加限制条件,然后去掉冗余的限制条件。
放东西就是这个道理,越常用的越要放在能快速拿的地方。我们的世界不是游戏里抽象的仓库,而是具有一个存储的层次结构,有远近难易之分。
有记忆的统计来自于局部性,它认为已有之事后必再有,已行之事后必再行。我之前觉得有道理,后来觉得也未必,有些东西摒弃掉了就是摒弃掉了,可能会在别的个体上持续发生,但在单个个体上未必。这有点算是抬杠了,总之呢,局部性可以大大提高性能。
无条件跳跃可能导致死循环啊,或者莫名其妙鬼畜起来了。虽然对于复杂的过程来说,未知错误是难免的,但还是尽可能把会出错的地方修补一番,然后在关键的地方用try与catch。
映射表的查找方法,如果虚拟内存和物理内存之间的映射表的查询方式是顺序查找,映射表又很长,查的位置不满足局部性来回跳,那时间就会花费很多,这么大的宏观的事可能不是我该考虑的,我就把他缩小吧。要是我建立一个用于存储和查询的表,我就会尽量让他们的序号有一定的意义,至少可以让我或者程序估计,要查的东西在前一半还是在后一半,哦我想起来了,这是不是设计了主键的排序呢?我真是笨蛋。
除了排序也可以分级,手动地告诉代码,要找的东西在上一半还是下一半,分两级就更加好找了。(过于幼稚)
层之间的关键字可以用门电路连接,这样的话很客观安全,但是是牺牲了物理空间换去来速度伤的性能。没有两全法的。只有取舍。
借用必须要有借用恢复,有点像中断。
需要保持状态的块,还是很经典的一句话,出门要有锁存,进门要有缓冲。
去掉冗余,相同的部分只写一次,这就是C的优势哦,不,是共享的优势。
创建一个垃圾堆,或者垃圾堆也可以临时使用,多想想如何把现实中的概念应用到虚拟的领域,这样或许我们分不清梦境与现实之前,就已经分不清虚拟与现实了。
大块与碎片的概念也很好,整可以碎,碎不可以整也。
相邻的块要比破碎的块更好用,不相邻就要花费一部分出来连接破碎的块,可能也需要花时间挑选出合适或足够的块们。
am有和没有区别很大,需要重视。
显示地初始化为0十分重要,要注意。
动作的前面都会加入一个隐含的形容词,请求。
知其然容易,知其所以然难。我知前者少,知后者更少,怎么会说话呢?不好意思啦。
虽然看不懂的多,但还是有收获的,加油!
或许会二刷吧。或许。