我在大学辅修数学。虽然我一直都很喜欢数学，但在日常的计算机编程中，我却出人意料地很少用到它。也许这就是为什么我对最新的Byobu版本感到兴奋的原因。BYOBU-2.12和2.13引入了一些巨大的性能增强，主要围绕状态收集脚本。我仔细地梳理了每一个细节，试图使它们尽可能高效。我编写了一个测试框架，运行这些脚本数百万次，以确定最昂贵的操作。改进主要涉及减少收集和打印信息所需的shell和fork数量，以及使用驻留在内存中的文件，如/var/run和/proc。从长远来看，这些脚本可能会比编译后的C程序执行得更好。但是我还不愿意放弃当前shell脚本的简单性和可移植性。除了脚本内容之外，我还修改了它们运行的时间间隔。在Ubuntu 9.04中，Screen-profile-1.44以以下间隔运行状态脚本：秒STATUS2 cpu-freq2 load-average2 mem-used2 network-down 2 network-up2进程2个重启-需要2 wifi-quality 10个更新-可用10个用户30个电池60个正常运行时间600 ec2-ost 3600主机名3600版本86400 arch86400 cpu-count86400 logo86400 mem-availe3600版本86400 arch86400 cpu-count86400 logo86400 mem-available。
这意味着：每隔2秒，Byobu将运行以下各项(CPU频率、平均负载、内存使用量、网络关闭、网络启动、进程、需要重启、WiFi质量)。
这些特殊的间隔导致了一些不幸的谐波，这在比奥布的响应性方面不是一件好事。例如，电池脚本每分钟只运行两次，因为它相对昂贵。但是，在30秒间隔，电池脚本还必须与10秒和2秒脚本共享时间。正如你所看到的，我们将会有几个驻波，这会定期导致一些相当昂贵的BYOBU状态栏刷新。据报道，这是几个错误，并指出Byobu会导致屏幕每隔2秒左右卡顿一次，延迟更长，为10秒。在旧版本的Byobu中，如果您打开所有状态通知，然后滚动浏览一个相当长的文件，您会看到它每隔几秒钟就会暂停或断断续续。尝试执行`find/lib|less`，然后按住向下箭头键。我们怎么解决这个问题呢？质数！如果我们将Byobu状态更新设置为主要间隔，而不是(2，10，30，60，...)，我们可以极大地减少昂贵的复合更新。我们可以随着时间的推移更均匀地分布更新，而不会堆积太多更新，也不会创建特别昂贵的间隔。根据对每个脚本的自动测试和统计分析，Byobu现在配置为以以下质数间隔运行状态脚本：秒STATUS2 cpu_freq2 load_average3 network5 mail5 reboot_required 7个进程11个用户13个磁盘13 mem_used17 wifi_quality19 temp_c19 temp_f29正常运行时间61个电池181 update_available599版本601 ec2_cost607 hostname613 ip_unity19 temp_c19 temp_f29 uptime 61 battery181 update_availe599 Release 601 ec2_cost607 hostname613 ip_。
现在，在任何给定的时间间隔，我们将只运行与该间隔的主要因素相对应的状态更新。因此，我们只运行5个脚本(cpu_freq、load_verage、network、mail、reboot_Required)，而不是在旧模型中运行12个脚本，而不是以60秒的速度运行一组相对昂贵的更新！下表显示了x轴上的时间(以秒为单位)，以及需要在y轴上运行的脚本数量。红色的数据来自Screen-profile-1.44(在Ubuntu9.04中)，蓝色的数据来自current byobu-2.13(Karmic)。我们减少了平均每秒需要运行的脚本数量。更重要的是，我们极大地降低了以前在任何时候运行十几个或更多脚本时达到峰值的谐波峰值。在最新的Byobu版本(2.13)中，响应性应该要好得多。网络状态项仍然是最昂贵的通知，但即使是它也有所改善。不过，在关闭网络项目的情况下，您的Byobu会话中应该不会出现明显的卡顿。获胜的质数！：-达斯汀