幹壞事是進步最大的原動力
在「» Feature: Garbage Collection Statistics」這邊看到 Xdebug 2.6 將能夠收集 PHP 的 GC (garbage collection) 行為了：
Xdebug's built-in garbage collection statistics profiler allows you to find out when the PHP internal garbage collector triggers, how many variables it was able to clean up, how long it took, and how how much memory was actually freed.
這樣 profiling 看的東西就更準確了...
前幾天提到 Apple 在新版 iOS 上搞出的電池問題：「iPhone 換電池恢復效能的事情傳到 Geekbench 後...」，結果看起來是 PR 部門整個加班處理 XDDD
台灣版的公告在「致廣大顧客關於 iPhone 電池與效能的說明」這邊可以看到，英文版的則是在「A Message to Our Customers about iPhone Batteries and Performance」這邊。
前面講的都是大家都已經知道的事情了，重點在後續的部份：
- Apple 為需要更換電池的 iPhone 6 或後續機種使用者，降低更換已過保固期的 iPhone 電池價格，從 NT$2,590 降為 NT$890，降幅為 NT$1,700。自 2018 年 1 月底至 12 月，全球同步進行。詳細優惠資訊將在近期於 apple.com/tw 公布。
- 在 2018 年初，我們將發布一項 iOS 軟體更新，其中的新功能可為使用者更清楚顯示 iPhone 電池的健康狀態，讓他們可以自己看到電池的狀態是否影響效能。
- Apple is reducing the price of an out-of-warranty iPhone battery replacement by $50 — from $79 to $29 — for anyone with an iPhone 6 or later whose battery needs to be replaced, starting in late January and available worldwide through December 2018. Details will be provided soon on apple.com.
- Early in 2018, we will issue an iOS software update with new features that give users more visibility into the health of their iPhone’s battery, so they can see for themselves if its condition is affecting performance.
所以總算是能在 iPhone 上面直接看到電池的情況了...
在「iPhone 的電池與效能」這篇提到了 iPhone 換電池可以恢復效能，結果 Geekbench (也就是原來在 Reddit 上抱怨的人用的測速軟體) 的 John Poole 從 Geekbench 的回報資料庫裡分析了資料，發現了特別的現象後寫下這篇文章 (於是後來引發一連串報導，以及 Apple 的 PR 事件)：「iPhone Performance and Battery Age」。
他先拿 iPhone 6S 分析，這看起來就不太妙：
再拿 iPhone 7 的資料分析，就更確定不妙：
可以看到 iOS 的 10.2.1 與 11.2.0 有奇怪的效能集中區。
後續蘋果也確認會刻意降速：「Apple addresses why people are saying their iPhones with older batteries are running ‘slower’」。
然後最新的發展就不太意外了，開始要打架了：「Days after iPhone battery fiasco, lawsuits against Apple begin to mount」。
接下來是耶誕假期，應該要等明年才會有新消息了...
在「Tracking CPU with Long Tasks API」這邊提到的現象，雖然是在提新的 API，不過裡面提到了很重要的問題。
以前的網站因為 js 都沒有用的那麼多，所以主要的瓶頸在於網路速度。所以大家最佳化的方向都是往「如何讓傳輸量變小」的方式進行，像是各類 js 的 minify，甚至是對 Gzip 演算法的暴力改善 (維持相容的 Zopfli，以及新的 Brotli)：
In the old days, delivering a fast user experience depended primarily on download speed. One reason why the network was the main bottleneck back then is that JavaScript and CSS weren’t used as much as they are now, so CPU wasn’t a critical factor.
而現代網站使用 js 的情況已經是來到了新的境界 (甚至很多網站是沒有 js 就不會動)，於是對於 CPU 的能力就愈來愈要求：
According to the HTTP Archive, the top 1000 websites download five times more JavaScript today compared to seven years ago.
而手機也愈來愈普及，CPU 的能力相較起來就更嚴峻了...
看到「That time Larry Ellison allegedly tried to have a professor fired for benchmarking Oracle」這篇文章的講古，想起很久前就有聽過 Microsoft 有這樣的條款 (禁止未經原廠同意公開 benchmark 結果)，原來是 Oracle 在三十幾年前創出來的？而且這種條款還有專有名詞「DeWitt Clauses」，出自當初被搞的教授 David DeWitt...
Microsoft 的條款是這樣：
You may not disclose the results of any benchmark test … without Microsoft’s prior written approval
Oracle 的則是：
You may not disclose results of any Program benchmark tests without Oracle’s prior consent
IBM 的反而在 license 裡面直接允許：
Licensee may disclose the results of any benchmark test of the Program or its subcomponents to any third party provided that Licensee (A) publicly discloses the complete methodology used in the benchmark test (for example, hardware and software setup, installation procedure and configuration files), (B) performs Licensee’s benchmark testing running the Program in its Specified Operating Environment using the latest applicable updates, patches and fixes available for the Program from IBM or third parties that provide IBM products (“Third Parties”), and © follows any and all performance tuning and “best practices” guidance available in the Program’s documentation and on IBM’s support web sites for the Program…
在 Hacker News 上看到 Reddit 上的這則說明：「PSA: iPhone slow? Try replacing your battery!」。
他提到他的 iPhone 6S 很慢，本來以為是 iOS 11 導致的，結果發現他弟弟 (或是哥哥？) 的 iPhone 6 也是跑 iOS 11，但是快很多... 所以他就試著研究，最後決定換電池：
My iPhone 6S has been very slow these past few weeks, and even after updating multiple times, it was still slow. Couldn’t figure out why, but just thought that iOS 11 was still awful to me. Then I used my brother’s iPhone 6 Plus and his was... faster than mine? This is when I knew something was wrong. So, I did some research, and decided to replace my battery.
結果發現換電池後速度就上來了，上面這張是換電池之前，下面那張是換電池之後：
所以是在電力不足的情況下會降速？
在 iOS 上測試的軟體是 Geekbench 4，而官方也有給參考值 (Geekbench 的)，在 iOS Benchmarks - Geekbench Browser 可以參考。如果在吃滿電、重開機，沒有背景的情況下還是很慢的話，有機會是類似的問題？
AWS 宣佈 Amazon EBS 可以提供的效能往上提高了 (這邊講的是 Provisioned IOPS SSD，代號 io1)：「Amazon EBS Improves Performance for io1 Volumes」。
單一 volume 的 IOPS 從 20K 變成 32K，thoughput 從 320MB/sec 變成 500MB/sec：
Today we are announcing an improvement in performance of Provisioned IOPS SSD (io1) Volumes from 20,000 IOPS to 32,000 IOPS and from 320 MB/s to 500 MB/s of throughput per volume.
應該是科技的進步帶動的 XD
Percona 的人分析了在 Amazon EC2 上跑 Percona XtraDB Cluster (PXC) 效能 (I/O bound)：「Best Practices for Percona XtraDB Cluster on AWS」。
先看他們做出來的圖：
直接跳到結論的地方。如果資料可以掉，用 i3 本地 storage 的效能是最好的，如果要資料不能掉，用 EBS 的 Provisioned IOPS SSD (io1) 的效能會比 General Purpose (gp2) 好很多。
另外 instance type 的選擇上，避免用 {i3,r4}.large，因為測試出來發現 {i3,r4}.xlarge 的效能好不只一倍。
不過 Aurora 的 Multi-master 已經在 Preview 了啊，如果 Percona 的人拿到帳號的話，應該會有單位成本的效能比較可以看...
Amazon EC2 直接租整台主機出來了：「Amazon EC2 Bare Metal Instances with Direct Access to Hardware」。
Bare Metal 怎麼翻譯比較好啊？雖然知道是拔掉虛擬化的主機... 裸奔機？
We knew that other customers also had interesting use cases for bare metal hardware and didn’t want to take the performance hit of nested virtualization. They wanted access to the physical resources for applications that take advantage of low-level hardware features such as performance counters and Intel® VT that are not always available or fully supported in virtualized environments, and also for applications intended to run directly on the hardware or licensed and supported for use in non-virtualized environments.
反正這種機器就是要壓榨整台機器的效能，所以不會拿小台機器出來給大家玩。這次推出的是 i3 系列，叫做 i3.metal：
Today we are launching a public preview the i3.metal instance, the first in a series of EC2 instances that offer the best of both worlds, allowing the operating system to run directly on the underlying hardware while still providing access to all of the benefits of the cloud. The instance gives you direct access to the processor and other hardware, and has the following specifications:
Processing – Two Intel Xeon E5-2686 v4 processors running at 2.3 GHz, with a total of 36 hyperthreaded cores (72 logical processors).
Memory – 512 GiB.
Storage – 15.2 terabytes of local, SSD-based NVMe storage.
Network – 25 Gbps of ENA-based enhanced networking.
走了十年總算走到這塊了... 不過應該花了不少時間解決各種安全性的問題，像是 network isolation 以及反刷韌體的問題 XD
作者寫了一篇「Creating Rust-based NodeJS modules」講同樣演算法 Node.js 要跑 3.5 秒，Rust 只要跑 130ms，所以 Rust 很棒棒之類的...
So about 3.5 seconds for an answer, in web time that is like an eternity. Our algorithm is a very straight forward one, basically just a filter on a large array.
The exact same algorithm, with the exact same CSV and coordinates is now executing in about 130ms.
然後仔細看了一下他的範例，holy...
這讓我想到之前在「看到 zmx 貼了之前的連結，更確信 Uber 的問題不是技術問題了...」這篇提到的文章「Unwinding Uber’s Most Efficient Service」：
TLDR;
Uber：傳統方式太複雜了根據我們資料特性自創一套高效能的空間索引服務。
前 Bing 員工：買了 Bing 怎麼不問專家啊？Quadtree 降兩個數量級啊，不然你們自創的做了這個小修改也是降兩個數量級啊！https://t.co/nHw1DgmYtU— zmx (@zmx) August 2, 2016
很想講「傻逼你先把演算法修好再來怪 Node.js 慢」，程式會愈來愈難維護都是你們這種人引入一堆複雜的東西 -_-