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\&notify\),为了代码复用和简单架构,我在暴力轮询的循环里加了\(sleep(10)\),就能够控制\(CPU\) \(time\)\(1s\)左右。

没有请求队列,模拟现实生活中的楼房\(Building\)类和楼层\(Floor\)类,将请求无条件放在对应楼层,电梯再去取人,所有的同步锁都只放在\(Floor\)类中,避免死锁。

多电梯中,将\(A,B,C\)三部电梯对应到三个不同的\(Building\)对象,用一个分配器分配,分配策略为平均(摸了)。

posted @ 2019-04-26 16:56  HugeGun  阅读(375)  评论(0编辑  收藏  举报