OO第二单元优化博客
OO第二单元优化博客
第五次作业没有性能分,但是,我在这一单元的宗旨就是写一个日常生活中 最常见的那种电梯,所以第五次我没有写傻瓜电梯,而是直接写了个\(look\),和第六次基本相同。
总计一下look算法的几个特点:
1、没有主次请求的区分。
2、电梯会一直往当前方向运行直到需要转向,转向条件为:
(1)当前电梯中没有乘客的目的楼层在当前方向上。
(2)当前方向上的楼层目前没有请求。
3、捎带时只捎带请求与当前方向相同的乘客。
(由于第五次第六次作业没有容量限制,所以可以把当前楼层上的所有请求全部拿进来)
另外,还有一些奇怪的优化:
1、在\(close\)和\(arrive\)时候记一下时间\(t_1\),下一次运行的时候可以根据当前时间\(t_2\),少\(sleep(t_2-t_1)\)的时间。
2、若电梯长时间没有收到请求,可以利用休息的时间\(t\),根据下一次需要到达的楼层来节约时间。
在第五次作业中,每次可以节约\(min([t/500ms],|target-now|)*500ms\)的时间;
在第六、七次作业中,由于需要输出\(arrive\),最多每次能节约\(400ms\)
这种反现实优化被我们称为“薛定谔电梯”,直观上来看,就是100%预测下一次的运行方向和楼层数,休息的时候直接往那里走,被称为薛定谔是因为:在你给出下一个请求之前,你永远不知道我的电梯到底在哪(第五次作业)。
关于架构上的感悟&多电梯:
第五次作业的\(CPU\) \(time\)限制支持暴力轮询;
第六次第七次大部分同学应该都用的\(wait\¬ify\),为了代码复用和简单架构,我在暴力轮询的循环里加了\(sleep(10)\),就能够控制\(CPU\) \(time\)在\(1s\)左右。
没有请求队列,模拟现实生活中的楼房\(Building\)类和楼层\(Floor\)类,将请求无条件放在对应楼层,电梯再去取人,所有的同步锁都只放在\(Floor\)类中,避免死锁。
多电梯中,将\(A,B,C\)三部电梯对应到三个不同的\(Building\)对象,用一个分配器分配,分配策略为平均(摸了)。